Times are UTC Toggle Colours
00:12:40 *** Seberoth has quit IRC 00:55:30 *** OwenS has joined #openttdcoop.devzone 01:18:06 *** thgergo has quit IRC 06:25:52 <planetmaker> good morning 06:29:20 <Brot6> FIRS Industry Replacement Set - Revision 1312:e107a6f1589b: Feature: improved Sand Pit graphics (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/e107a6f1589b 08:24:26 *** Seberoth has joined #openttdcoop.devzone 08:38:13 *** ODM has joined #openttdcoop.devzone 09:13:42 <Brot6> OpenGFX - Bug #1388 (Closed): check station roofs' transparency (planetmaker) @ http://dev.openttdcoop.org/issues/1388 09:13:42 <Brot6> OpenGFX - Revision 520:670823c18970: Fix #1388 (r450): No more broken glass on station roofs (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/670823c18970 09:13:42 <Brot6> OpenGFX - Bug #1388 (Closed): check station roofs' transparency (planetmaker) @ http://dev.openttdcoop.org/issues/1388#change-3712 09:21:54 <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (planetmaker) @ http://dev.openttdcoop.org/issues/839#change-3713 09:28:38 <Brot6> OpenGFX - Feature #1255: Gumdrops for Toyland Lighthouse and Radio Antenna (planetmaker) @ http://dev.openttdcoop.org/issues/1255#change-3714 10:25:46 <Brot6> FIRS Industry Replacement Set - Feature #1389 (Assigned): For INCOMPATIBLE_VERSION14, state what ... (foobar) @ http://dev.openttdcoop.org/issues/1389 10:36:38 *** KenjiE20 has joined #openttdcoop.devzone 10:45:03 <Brot6> FIRS Industry Replacement Set - Feature #1389: For INCOMPATIBLE_VERSION14, state what OpenTTD ver... (planetmaker) @ http://dev.openttdcoop.org/issues/1389#change-3715 10:47:16 <Brot6> FIRS Industry Replacement Set - Feature #1303: Include action14 strings into translations (planetmaker) @ http://dev.openttdcoop.org/issues/1303#change-3716 10:49:03 <Brot6> FIRS Industry Replacement Set - Feature #1305: Detect missing strings (planetmaker) @ http://dev.openttdcoop.org/issues/1305#change-3717 10:50:26 <Ammler> Froix didn't get my hint to make his own thread for the trees ;-) 10:51:49 <planetmaker> :-) Nvm it 10:52:04 <Brot6> FIRS Industry Replacement Set - Feature #1305: Detect missing strings (planetmaker) @ http://dev.openttdcoop.org/issues/1305#change-3717 10:52:04 <Brot6> FIRS Industry Replacement Set - Revision 1313:1014da1cc6f1: Fix #1362: Don't include nfo header t... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1014da1cc6f1 10:52:04 <Brot6> FIRS Industry Replacement Set - Bug #1362 (Closed): Duplicate NFO header (planetmaker) @ http://dev.openttdcoop.org/issues/1362#change-3718 10:52:05 <planetmaker> But you're right :-) 10:55:21 <Ammler> he has already a newgrf, so he doesn't look for a coder, does he? 10:57:01 <planetmaker> Yes he knows how to deal with that 10:57:13 <planetmaker> He's the same one as with the Shanghai maglev 10:58:19 <Ammler> maybe we can ask him to make snowy temperate trees from the already opengfx trees 10:58:19 <Brot6> FIRS Industry Replacement Set - Feature #1389: For INCOMPATIBLE_VERSION14, state what OpenTTD ver... (planetmaker) @ http://dev.openttdcoop.org/issues/1389#change-3715 10:58:19 <Brot6> FIRS Industry Replacement Set - Revision 1314:cc8c7b765581: Feature #1305: change to the script l... (Ammler) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/cc8c7b765581 10:59:14 <planetmaker> Actually _I_ wouldn't mind to have those trees in OpenGFX 10:59:17 <Ammler> shall I add that script to the build script, or does the makefile already run it? 10:59:34 <planetmaker> what script? 10:59:43 <Ammler> the missing strings thing 10:59:58 <planetmaker> it's not run automatically 11:00:05 <planetmaker> But it's not needed either. 11:00:10 <planetmaker> Missing translations are no error 11:00:14 <Ammler> nah 11:00:31 <Ammler> not for abort, but for the errors log 11:04:27 <Ammler> isn't it a error 11:04:34 <Ammler> if a undef is missing? 11:05:12 <Ammler> and it seems that is all what that script does, it doesn't check for missing translations 11:05:41 <Ammler> IMO, you should incldue to make and fail 11:07:21 <planetmaker> There will never be an undef missing :-) 11:07:29 <planetmaker> There will only be one too much 11:07:40 <planetmaker> for those which are not defined in the translated language 11:07:57 <planetmaker> And that's a non-op 11:08:28 <Ammler> oh, so the undef is generated automatically? 11:08:33 <planetmaker> No 11:08:48 *** thgergo has joined #openttdcoop.devzone 11:08:49 <Ammler> hmm, so how will there never be one missing? 11:08:56 <planetmaker> if you define a new English string, you also undef it 11:09:13 <planetmaker> and the same undef file is used for every language 11:09:26 <Ammler> yep, but the undef isn't checked, is it? 11:09:39 <planetmaker> it isn't 11:09:55 <Ammler> hmm, shouldn't the undef script be a sed of english? 11:10:11 <planetmaker> That'd be ideal, yes 11:17:33 <Terkhen> the script can be used for checking missing translation too, you only need to pass it a part of the translation file as a parameter (for example check_language 04 or check_language spa will check the spanish translation) 11:18:04 <Terkhen> and IMO missing strings at remove_defines should be treated as an error 11:18:59 <planetmaker> yes, they are that. But generating that file automatically would avoid that error ;-) 11:19:13 <Brot6> FIRS Industry Replacement Set - Feature #1390 (New): Feature: Generate lang/remove_defines.pnfo a... (planetmaker) @ http://dev.openttdcoop.org/issues/1390 11:21:00 <Terkhen> indeed :) 11:21:12 <planetmaker> hm. Script done :-P 11:22:49 <Brot6> FIRS Industry Replacement Set - Feature #1390: Feature: Generate lang/remove_defines.pnfo automat... (Ammler) @ http://dev.openttdcoop.org/issues/1390#change-3720 11:29:28 <Brot6> FIRS Industry Replacement Set - Feature #1390: Feature: Generate lang/remove_defines.pnfo automat... (Ammler) @ http://dev.openttdcoop.org/issues/1390#change-3720 11:35:13 <Ammler> planetmaker: where are the docs of opengfx? 11:36:39 <planetmaker> in the docs folder? 11:36:45 <Ammler> only ptxt 11:36:49 <Brot6> FIRS Industry Replacement Set - Feature #1390: Feature: Generate lang/remove_defines.pnfo automat... (planetmaker) @ http://dev.openttdcoop.org/issues/1390#change-3721 11:37:12 <planetmaker> yeah, they're currently in docs, too 11:37:16 <planetmaker> and in $DIR_NAME 11:37:26 <planetmaker> But... don't rely on any of those two 11:38:19 <Ammler> they aren't in both 11:38:29 <planetmaker> did you run make docs? 11:38:36 <planetmaker> if you only run make, they're not built 11:39:10 <Ammler> I run make bundle_zip 11:39:16 <Ammler> the zip is without 11:39:53 <Ammler> make: Nothing to be done for `docs'. 11:40:21 <Ammler> ./sprites/source/missing_chars.txt <-- the only txt file 11:41:02 <Ammler> make should really build the docs 11:41:14 <Ammler> you just need to differ for installation 11:41:15 <planetmaker> no. Make bundle is enough 11:41:31 <planetmaker> If make bundle* doesn't build it, it's a bug indeed 11:41:35 <planetmaker> But make need not build it 11:42:27 <Ammler> yep, take this as a bug report :-) 11:42:38 <planetmaker> I'll forget it ;-) 11:44:54 <Ammler> hmm, I wonder, why the CF didn't complain 11:45:03 <Ammler> maybe I should flag the readme with "R" 11:50:28 <planetmaker> what should the CF have complained about? 11:50:35 <planetmaker> oh... nvm. The missing docs 11:52:51 <Brot6> Example NewGRF Project - Feature #1391 (New): Version check for "tools" and abort (Ammler) @ http://dev.openttdcoop.org/issues/1391 11:53:08 <planetmaker> well. maybe. But... then read the definitions from the Makefile 11:53:19 <planetmaker> Or the configuration therein becomes void 11:53:27 <planetmaker> or rather pointless 11:54:53 <Brot6> Example NewGRF Project - Bug #1392 (New): make builds no docs (.txt) files anymore (Ammler) @ http://dev.openttdcoop.org/issues/1392 11:57:25 <planetmaker> Ammler, testing which which project...? 11:57:37 <Ammler> yep, that is why I made the report there :-) 11:57:37 <planetmaker> which revision? which call? 11:57:43 <Ammler> all 11:57:53 <Ammler> well, I tested ogfx and firs 11:58:33 <planetmaker> and you called make bundle_zip? 11:59:03 <planetmaker> hm... yes :S 11:59:14 <planetmaker> damn damn.... yet another patch in my growing makefile patch queue 11:59:50 <Ammler> no 11:59:54 <Ammler> I just run make 12:00:05 <Ammler> that should be enough for building 12:00:29 <Ammler> installing is the next step... :-) 12:00:35 <planetmaker> no. Docs should not be build by calling make 12:00:47 <Ammler> mäh 12:00:47 <Brot6> Example NewGRF Project - Bug #1392 (New): make builds no docs (.txt) files anymore (Ammler) @ http://dev.openttdcoop.org/issues/1392 12:01:04 <Ammler> that is ugly 12:01:05 <planetmaker> They only need building when you build a bundle 12:01:16 <Ammler> I like to have up2date docs 12:01:22 <planetmaker> then make docs 12:01:37 <Ammler> I like "others" to have up to date docs 12:02:00 <planetmaker> Ammler, docs are never generated on a call to make 12:02:11 <Ammler> that is really bad 12:02:36 <Ammler> are you sure, it wasn't before? 12:03:01 <Ammler> I rarly run make <something> local 12:03:10 <Ammler> and I had txt files 12:03:58 <planetmaker> it's generated when you call install, of course 12:04:10 <planetmaker> But I'm sure it has been this way since r0 12:04:48 <Ammler> if so it is wrong since r0 12:06:18 <Ammler> just made "hg up 100 && make" and txt files are there 12:06:30 <Ammler> (in ogfx) 12:07:25 <Ammler> well, anyway, the split the ticket to a urgent bug and a low prio feature request :-) 12:14:18 <planetmaker> I consider it a bug request 12:15:36 <planetmaker> when I make a newgrf I don't need its documentation done 12:15:43 <planetmaker> I test whether the newgrf compiles 12:15:55 <planetmaker> It's a development tool 12:16:07 <planetmaker> I only need the documentation when I ship the thing 12:16:28 <Ammler> the readme does also have dev docs like the build targests 12:17:09 <Ammler> and what is a "bug request"? 12:17:15 <Ammler> :-D 12:17:47 <Ammler> well, at least for the bundles, there should be docs, so that part is urgent 12:18:14 <Ammler> there other part, I will learn to life with it :-( 12:19:23 <Ammler> it would be a "Feature revive request" :-) 12:20:06 <Ammler> I am sure, you confused building and installing... 12:20:35 <planetmaker> `all' 12:20:36 <planetmaker> Compile the entire program. This should be the default target. This target need not rebuild any documentation files; Info files should normally be included in the distribution, and DVI files should be made only when explicitly asked for. 12:20:39 <planetmaker> ^^ 12:21:25 <planetmaker> as such I go by the official makefile documentation 12:21:25 <Ammler> yes, user docs maybe 12:21:35 <planetmaker> there are no other docs 12:21:47 <Ammler> the readme has infos about building, doesn't? 12:22:28 <planetmaker> yes. 12:22:51 <planetmaker> As such the argument could be: Ship pre-compiled documentation with the tar balls 12:23:24 <planetmaker> +source 12:24:59 <Ammler> but you know, it doesn't build also for bundles? 12:27:02 <planetmaker> I know now. 12:27:11 <planetmaker> And that is a real problem 12:27:14 <Brot6> Example NewGRF Project - Bug #1392: make builds no docs (.txt) files anymore (Ammler) @ http://dev.openttdcoop.org/issues/1392#change-3722 12:27:50 <Ammler> [13:39] <Ammler> I run make bundle_zip 12:27:52 <Ammler> [13:39] <Ammler> the zip is without 12:30:35 <planetmaker> yes :-) I know since then :-) 12:31:03 <planetmaker> now is a relative time span :-P 12:31:34 <planetmaker> http://www.longnow.org/ 12:31:36 <Webster> Title: Front Page - The Long Now (at www.longnow.org) 12:32:08 <Ammler> maybe, there is no need to cpp the opengfx readme at all 12:33:00 <Ammler> you are member? 12:37:36 <planetmaker> I'm not a member. But I find it kinda a cool project 13:21:52 *** GT has joined #openttdcoop.devzone 13:45:00 <DJNekkid> yey, a14-support for 2cc-set isnt THAT much work afterall! :D:D 13:46:46 <planetmaker> :-) 13:52:21 <DJNekkid> _most_ stuff is "outside" of the language-file 13:52:28 <DJNekkid> there is "only" the engine names thats inside 13:53:40 <DJNekkid> and excel is, as always, my friend :D 13:53:46 <GT> If I have actions 2 and 3 in 32bpp_extra.grf, does that make it unsafe for static usage? 13:54:12 <GT> Hi, btw 13:54:29 <DJNekkid> hi 13:54:30 <DJNekkid> and; yes 13:54:38 <DJNekkid> *most* likely 13:55:33 <GT> ogfxe_extra also does have them, but probably gets away with it because it is a *real* base set? 13:56:23 <DJNekkid> unless ogfxe_extra isnt socall "opengfx+" thats not a base-set, its an "addon" to opengfx 13:57:24 <Ammler> GT, what is the use to add such things to 32bpp_extra? 13:57:32 <Ammler> I thought, that is used for 32bpp only? 13:58:20 <Ammler> if you have some "special" 32bpp graphcis, add a newgrf to the tar 13:58:57 <planetmaker> GT, ogfxe_extra gets away with it as it's part of a base set, yes 13:59:09 <planetmaker> the action2/3 stuff in it is fishy nevertheless 13:59:15 <Ammler> really? 13:59:19 <Ammler> :-o 13:59:45 <GT> Why are they there anyway, to randomize the waterworks per climate, or something? 13:59:45 <planetmaker> that's my understanding :-) 13:59:59 <planetmaker> No. per-climate stuff doesn't need action2/3 14:00:06 <Ammler> you want to remove the rivers? 14:00:12 <planetmaker> No :-P 14:01:00 <planetmaker> I've not looked at the water part for ages, but afair it is needed to supply the sprites in their current form; maybe some random stuff, I don't exactly know. Maybe for the slope-awareness 14:01:05 <Ammler> GT climate switches are Action7, no problem to use 14:02:03 <GT> Yes, but the action 7s are used to skip an action 3, that is used to select one of multiple actions2 if Im correct, Im not a newgrf expert 14:02:22 <GT> (talking about ogfxe_extra) 14:02:23 <planetmaker> action7 is just a jump. Whatever it jumps... 14:02:36 <GT> it jumps an action 3 14:02:43 <planetmaker> that's fine 14:02:56 <GT> depending on the climate 14:02:58 <planetmaker> but the action3 is what makes a newgrf afaik non-static 14:03:21 <Ammler> yes, but opengfx_extra doesn't need to be static 14:03:22 <GT> right, so I was wondering why they are there 14:03:35 <Ammler> just "MP"-safe :-) 14:03:35 <planetmaker> just because we can :-P 14:03:55 <Ammler> or it is a bug in the static checking... 14:04:03 <planetmaker> And we can - despite this non-static influence - do that for two reasons: 14:04:12 <planetmaker> - it doesn't have a game-changing influence in MP 14:04:33 <planetmaker> - there's little or no water newgrfs which do more than relatively simple sprite replacements 14:04:37 <GT> :), PM, but what feature does it implement, in other words, if I rip them out for 32bpp-extra, what will i be missing 14:04:58 <Ammler> nothing 14:05:03 <planetmaker> dunno quite. Some nice things related to water tiles 14:05:08 <planetmaker> But nothing essential 14:05:19 <Ammler> everything can be done with a newgrf 14:06:06 <Ammler> well, if you have the 32bpp waters also in those variations, you can keep it 14:06:13 <GT> Ammler, the problem is that the initial screen does show some coast lines, that are not shown correct without the 32bpp-extra.grf, so I want to make it static 14:06:59 <Ammler> GT, I still would recommend to talk to the openttd devs to load 32bpp-extra alsways 14:07:04 <GT> (for 32bpp only that is) 14:07:09 <Ammler> yes 14:07:23 <Ammler> I assume, you do that already in the ez patch 14:07:41 <GT> no, not yet 14:07:42 <planetmaker> let me understand this: you obviously do more than a sprite-replacement there, adding your own water newgrf. And then it fails? 14:08:04 <Ammler> planetmaker: 32bpp-extra is like a newgrf, not like ogfx-extra 14:08:11 <Ammler> so it isn't loaded at openttd start 14:08:33 <planetmaker> yes. Of course not 14:08:42 <GT> unless it would be static 14:08:57 <planetmaker> Sure static works on the title screen? 14:09:15 <Ammler> mäh, what is bad about my idea? 14:09:27 <planetmaker> besides... can't you just provide the sprites in the same form as OpenGFX does? 14:09:35 <planetmaker> Wouldn't that solve the issue? 14:09:47 <GT> same form? 14:09:55 <Ammler> or what about branching opengfx baseset and make a 32bpp variant 14:10:03 <Ammler> where the only difference is the other extra file 14:10:14 <planetmaker> hm... doesn't 32bpp work the way that you provide the same sprite number as 32bpp and it gets drawn instead? 14:10:24 <planetmaker> Like... usual 32bpp sprites work in trunk? 14:10:38 <Ammler> yep, but you can't do that for ogfx_extra 14:10:45 <planetmaker> why not? 14:10:54 <Ammler> because there it changes the number 14:11:07 <planetmaker> when? Only when new sprites get added 14:11:12 <GT> you provide pngs with a number as in the nfo, and in the directory named after the newgrf, and then they get replaced 14:11:12 <Ammler> you missed that whole discussion? 14:11:51 <planetmaker> GT, ok, and then it still doesn't work with the water? 14:12:00 <Ammler> planetmaker: that is the whole point about the 32bpp-extra, what do you think is that grf for? 14:12:14 <GT> so when the openttdw.grf changes, every png would need to be renumbered, that is why we have a 32bpp-extra, that is the base for the png numbers 14:12:31 <GT> It is basically a copy of ogfxe_extra / openttdw, 14:12:47 <planetmaker> combined, right? 14:12:57 <planetmaker> hm... no 14:12:58 <GT> without the colour tables and some other useless stuff 14:13:17 <Ammler> if you branch opengfx, you would need that useless stuff 14:14:00 <Ammler> but you can append that to the end 14:14:04 <GT> only ogfxe_extra would need to be branched, the numbers in the other base grfs dont change 14:14:18 <Ammler> yes, but you need them in your baseset 14:14:24 <Ammler> you can't replace just one file 14:14:28 <planetmaker> GT, but numbers only change when sprites are added in the middle, right? 14:14:37 <GT> right 14:15:10 <planetmaker> So, would it help, if we added the water in the beginning? Then it's very unlikely to change, except if we change the water itself? 14:16:44 <GT> another problem is that the numbering between openttdw and ogfxe_extra is different, so players with different base sets, cannot use the same set of pngs, that is another reason for having the newgrf 14:16:46 <Ammler> hmm, I give up... 14:18:20 <planetmaker> hm, yes... Then you'll need to have the grf loaded statically 14:19:31 <planetmaker> GT, then you could do similar like for the base grfs: they require a certain GRFID FF XX YY ZZ (XX and ZZ are kinda fixed, too) and load it statically ,if that number is found 14:19:44 <planetmaker> ignoring possibly dangerous stuff 14:20:56 <planetmaker> alternatively we could produce a version without the action3 stuff... Did you by chance try an OpenGFX without it and test whether all your things then work out for you? 14:21:18 <planetmaker> I mean... should be moderately easy for you to build a custom version for testing purposes 14:21:30 <planetmaker> you have all the tools :-) 14:21:48 <GT> correct, but I first wanted to check that Im on the right track, that actions 3 are unsafe, 14:22:03 <planetmaker> yes, I *think* so. 14:22:13 <planetmaker> I didn't reply in the thread as I'm not 100% sure 14:22:29 <planetmaker> action2 is actually the critical one 14:22:31 <GT> I think Ammlers idea isnt that bad: when a 32bpp blitter is active, always try toload the 32bpp-extra grf 14:22:40 <planetmaker> but an action3 always refers to an action2 14:23:08 <planetmaker> GT, yes, possibly. But as said, require a certain GRFID, except the last byte of it 14:23:32 <planetmaker> look like how the check for the extra newgrf of base sets is done 14:24:44 * GT is going to do some experiments, thanks for the replies, cu 14:25:12 <planetmaker> no problem :-) 14:30:55 <Rubidium> hmm, so Mac OS X users always have to play with 32bpp-extra if it's found? 14:31:13 <Ammler> wouldn't matter 14:31:19 <Ammler> not supported os anyway ;-) 14:31:22 <Rubidium> (yes, recent Mac OS X builds don't support 8bpp) 14:32:11 <Ammler> hmm, is there another reason left to use 32bpp blitter then? 14:32:28 <Ammler> if you like to play with 8bpp graphcis 14:38:59 <Ammler> Well, most proper would be a branch of ogfx, also easiest to maintain... 14:39:58 * planetmaker kicks Ammler 14:40:01 <Ammler> branch ogfx, replace the ogfxe_extra.pnfo with your pnfo and you are done 14:40:04 <planetmaker> I don't support your notion 14:40:11 <Ammler> where? 14:40:22 <Ammler> ah :-) 14:40:23 <planetmaker> I don't want to be forced upon 32bpp 14:40:32 <Ammler> you aren't 14:40:35 <planetmaker> Or you can forget that I can test and develop OpenGFX 14:40:59 <Ammler> only, if you have the 32bpp-extra.grf in your share 14:41:36 <planetmaker> No. I actually think that OpenTTD needs a button *somewhere* which en- or disables the use of the 32bpp sprites, if the 32bpp blitter is active 14:42:13 <Ammler> or 32bpp graphcis should all be done as newgrfs :-) 14:42:26 <Ammler> or own baseset any you have the switch 14:44:19 <planetmaker> Hm. That *might* be best 14:44:45 <planetmaker> The modifications required would be on the bananas side mostly: allow additional 32bpp files in the uploaded base set 14:44:48 <Ammler> hmm, shall we merge ogfx and 32bpp-extra? 14:45:07 <planetmaker> Then 32bpp could 'just' add black 8bpp sprites and supply 32bpp for everything 14:45:17 <planetmaker> then the 5 original grfs would be tiny 14:45:35 <Ammler> I don't think, the 32bpp people fear the size :-) 14:45:37 <planetmaker> or is my assumption somewhere flawed? 14:45:51 <planetmaker> Ammler, but 3MB more or less do matter... 14:46:01 <Ammler> for a 100MB file? 14:46:15 <Ammler> where I would guess, around 50% is done maybe less 14:46:42 * Rubidium wonders whether they're ever going to pick up on my idea with NML :) 14:46:53 <Ammler> the 32bpp extra sprites are 7MB already 14:48:14 <Ammler> planetmaker: it is more the other side around, if we are ready to merge the 7MB from 32bpp-extra to our repo 14:49:08 <Ammler> I guess not, so the easiest is too clone ogfx and pull from time to time 14:49:15 <planetmaker> yes 14:49:33 <planetmaker> OpenGFX must not get needlessly larger by a few 100% percent 14:54:15 *** frosch123 has joined #openttdcoop.devzone 15:22:18 *** yorick has joined #openttdcoop.devzone 15:45:51 <Hirundo> [reading backlog] Rubidium: what idea with NML? 15:47:12 <Brot6> 2cc train set - Revision 593:471e3fd80adf: Change: in preparation for action14: (DJNekkid) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/471e3fd80adf 15:49:36 <Brot6> 2cc train set - Revision 594:18fb7c9c9cc7: Fix: Forgot to add a file in the prev. rev (DJNekkid) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/18fb7c9c9cc7 16:00:10 <Ammler> Hirundo: 32bpp support 16:01:07 <Hirundo> to automagically create png files with the correct naming/offsets etc? 16:01:36 <planetmaker> possibly 16:01:47 <planetmaker> But... that's kinda difficult and subjet to its own extension 16:01:50 <planetmaker> +c 16:08:42 *** frosch has joined #openttdcoop.devzone 16:08:55 <Ammler> Hirundo: yes, and creating the png files with name like the sprite number 16:09:43 <Hirundo> http://blog.client9.com/2007/08/python-pil-and-png-metadata-take-2.html <- writing the tEXt chunk should be possible 16:09:44 <Webster> Title: digital sanitation engineering: Python, PIL and PNG metadata, take 2 (at blog.client9.com) 16:10:36 <Ammler> basically you define beside the 8bpp png also the other pngs 16:10:45 <Ammler> (the zoom-level stuff) 16:11:58 *** frosch123 has quit IRC 16:11:59 *** michi_cc has quit IRC 16:11:59 *** SmatZ has quit IRC 16:11:59 *** tneo has quit IRC 16:12:07 *** frosch123 has joined #openttdcoop.devzone 16:12:07 *** michi_cc has joined #openttdcoop.devzone 16:12:07 *** SmatZ has joined #openttdcoop.devzone 16:12:07 *** tneo has joined #openttdcoop.devzone 16:12:22 *** frosch123 has quit IRC 16:13:42 <Hirundo> What's the current situation of the 32bpp stuff? Much activity? 16:14:21 <Ammler> well, they have basically no system and there is no big support from tools 16:14:29 <Ammler> it is very complicated to make 32bpp stuff 16:15:42 <Yexo> Hirundo: what nml needs first is a syntax for alternative graphics 16:15:51 <Brot6> 2cctrainset: update from r592 to r594 done (4 errors) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r594 16:16:16 <Yexo> we have a syntax to supply the filename/size/offsets for 8bpp sprites, but we need the same for 'alternative' graphics 16:16:33 <Yexo> where alternative is currently only 32bpp in normal zoom, but in a way that it can later be extended to extra zoom levels 16:16:51 <Brot6> firs: update from r1309 to r1314 done (883 errors) - http://bundles.openttdcoop.org/firs/nightlies/r1314 16:17:11 <Hirundo> As far as I can tell, those need the same information (xpos/ypos/xrel/yrel/xsize/ysize), although the rectangle to use of often the entire file 16:17:30 <Yexo> exactly 16:18:11 <Hirundo> We could say that specifying 0,0,0,0 as rectangle is equivalent to the entire file. 16:18:13 <Yexo> but I think it's better if we don't rely on the fact that it's often one sprite per file 16:18:34 <Yexo> I think it'd be a lot easier for them too if they could just copy a 8bpp sprite file and just draw over the 8bpp graphics 16:18:38 <Brot6> nforenum: update from r482 to r484 done - http://bundles.openttdcoop.org/nforenum/nightlies/r484 16:18:51 <Yexo> currently that's not possible because the tools don't support that 16:19:13 <Hirundo> That's for no-zoom? 16:19:28 <planetmaker> o_O @ FIRS errors.... did I screw up? 16:19:38 <Brot6> nutracks: update from r112 to r114 done (2 errors) - http://bundles.openttdcoop.org/nutracks/nightlies/r114 16:19:46 <Yexo> yes 16:19:54 <Yexo> for extra-zoom it might be different 16:19:56 <frosch> even normal zoom 32bpp can have two png per sprite 16:20:02 <Ammler> Hirundo: currently they have one file per sprite, but Yexo means, that it would be easier to have multiple sprites per file anyway 16:20:06 <planetmaker> frosch, two? 16:20:15 <Hirundo> CC mask 16:20:16 <Yexo> planetmaker: company color mask 16:20:19 <planetmaker> ah 16:20:20 <frosch> a rgfa one, and an indexed one for company colours and such 16:20:28 <frosch> though the latter is incompatible with extra-zoom afaik 16:20:29 <Ammler> planetmaker: I would wait for the rebuild :-) 16:20:46 <planetmaker> Ammler, not sure. IIRC I had those, too 16:21:00 <Brot6> opengfx: update from r519 to r520 done - http://bundles.openttdcoop.org/opengfx/nightlies/r520 16:21:07 <Ammler> me too, then I updated nforenum and the errors are gone 16:21:09 <Brot6> Following repos didn't need a nightlies update: 32bpp-extra (r38), airportsplus (r53), basecosts (r20), belarusiantowns (r0), comic-houses (r71), fish (r387), frenchtowns (r3), grfcodec (r244), heqs (r372), metrotrackset (r56), newgrf_makefile (r172), nml (r700), ogfxplus (r41), openmsx (r97), opensfx (r97), snowlinemod (r42), swedishrails (r147), swisstowns (r13), transrapidtrackset (r15), ttdviewer (r25), ttrs (r18), worldairlinersset 16:21:09 <Brot6> (r663) 16:21:28 <Ammler> theoretically it should annouce that... 16:23:33 <Hirundo> I assume that the lack of a complete, written spec is one of 32bpp's problems? 16:24:10 <Ammler> does trunk 32bpp support CC? 16:24:15 <Yexo> no, a lack of coordination 16:24:15 <frosch> yes 16:24:46 <Ammler> so why does ez needs "special support"? 16:24:48 <frosch> Hirundo: everyone who talks about 32bpp has different goals, so it is kind of hard to advance to the specs-writing-stage :) 16:24:59 <frosch> Ammler: ez does not recolour, but does some hue transition 16:25:27 <frosch> but i do not know the details, i only know the bugreports about 32bpp not working in trunk :p 16:25:54 <frosch> it's called "new experimental company colour algorithm" or so 16:26:04 <Hirundo> so RGB -> HSB -> shift hue -> RGB? 16:26:30 <frosch> yes, i would guess only for company colours though, but no idea 16:26:59 <Ammler> planetmaker: warnings are gone: http://bundles.openttdcoop.org/firs/nightlies/r1314/log/RELEASE-2.diff 16:27:09 <Ammler> strange is that it wasn't announced :-( 16:27:32 *** Seberoth has quit IRC 16:27:39 <frosch> Hirundo: it is at the very top of the diff 16:27:47 <frosch> http://dev.openttdcoop.org/projects/32bpp-ez-patches/repository/entry/ez.diff 16:29:41 <michi_cc> It's no wonder 32bpp isn't progressing as long as many people associate 32bpp with the last list from http://www.tt-forums.net/viewtopic.php?p=879945#p879945 and not with what it is: more colours at the same time. 16:29:43 <Webster> Title: Transport Tycoon Forums • View topic - To Do, Roadmap, Feature requests (at www.tt-forums.net) 16:29:46 <planetmaker> hm 16:29:52 <Hirundo> "declare variables at first use", "min() is not invented here, let's use our own" 16:29:57 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (4 errors), 32bpp-extra (1 errors) (Diffsize: 13), airportsplus (Diffsize: 1), basecosts (Diffsize: 11), comic-houses (3 errors) (Diffsize: 13), firs (Diffsize: 6327), fish (5 errors) (Diffsize: 1), heqs (Diffsize: 1), metrotrackset (Diffsize: 1), newgrf_makefile (Diffsize: 1), snowlinemod, transrapidtrackset (Diffsize: 12), ttrs (125 16:29:57 <Brot6> errors) (Diffsize: 1322), worldairlinersset 16:30:31 <Ammler> he, I don only announce, if a grf got worse, not better :-) 16:31:36 <frosch> does someone know what 32bpp does wrt. 2cc and house/bridge or newgrf supplied recolouring? 16:31:39 <Ammler> http://bundles.openttdcoop.org/firs/nightlies/r1314/log/REBUILD/r1314/ <-- same md5sum 16:31:56 <frosch> or are 32bpp houses not meant to be recoloured? 16:32:44 <planetmaker> no idea 16:33:14 <planetmaker> he, hi michi_cc :-) I never knew you were in this channel, too ;-) 16:35:07 <michi_cc> planetmaker: Your IRC client doesn't have a nick list? :) 16:35:31 <planetmaker> It does. And it's right on my screen to the right of all the text... but... :-) 16:40:04 * planetmaker wonders whether actually EZ and 32bpp are related... or rather should be related 16:42:01 <planetmaker> probably not 16:42:25 <planetmaker> As such EZ needs a sane algorithm to smoothly extrapolate graphics... 16:42:31 <Ammler> hmm, about nml, couldn't we with a kind of sed convert the opengfx to nml? 16:42:57 <planetmaker> OpenGFX base grfs might work 16:42:59 <Ammler> then we only need "special" work for the extra grf 16:43:03 <planetmaker> yes 16:43:22 <planetmaker> should be a moderately easy tasks. Both things actually 16:43:41 <Ammler> one spriteset per file, I guess? 16:44:12 <Ammler> well, we might have troubles with the already templated things 16:45:24 <planetmaker> hm. yes 16:45:53 <planetmaker> I suggest one sprite set per "set". Where "set" is a set of lines without empty line in between. 16:59:16 <planetmaker> GT still here? What indeed about the idea to propose an extra-zoom patch which only provides a zoom-in functionality? Independent of the bit-depth used? 16:59:26 <planetmaker> s/propose/provide/ 17:00:37 <planetmaker> GT, kinda implementing a hqx2 algorithm for that end is by the looks a nice idea. Might be not quite easy, though... 17:00:50 <planetmaker> But that way it might be moderately easy to get such thing into trunk 17:01:00 <planetmaker> It's a single feature. Doesn't touch other existing stuff... 17:08:16 <Ammler> that was the initial idea about makeing mq for the ez patch 17:09:48 <planetmaker> it might be complicated enough to warrant its own mq all by itself. 17:14:34 <DJNekkid> now ... 17:14:39 <DJNekkid> what parameters do the 2cc-set have 17:15:01 <DJNekkid> purchase/running costs? :) 17:15:06 <Ammler> default 9 17:15:29 <DJNekkid> perhaps separate running- and purchasecosts? 17:15:30 <Ammler> that's all I remember :-) 17:17:17 <planetmaker> DJNekkid, why not? :-) 17:17:43 <planetmaker> was there a region parameter? 17:17:49 <DJNekkid> there was :) 17:19:27 <DJNekkid> should we reintroduce it? 17:19:41 <planetmaker> did you remove it? 17:19:51 <DJNekkid> basicly 17:20:03 <DJNekkid> it seemed like it confused people 17:20:17 <planetmaker> With a14 it suddenly becomes accessible :-) 17:20:23 <DJNekkid> exactly 17:20:51 <planetmaker> well. Your choice basically. 17:20:58 <planetmaker> You could also put that off till 2.1 or so 17:22:16 <DJNekkid> so extensive regions still? 17:24:28 <planetmaker> Not sure :-) 17:24:40 <Brot6> 32bpp-extra - Revision 39:0451ecd5cc53: Add: devzone CF seems to need an md5 target (GeekToo) @ http://dev.openttdcoop.org/projects/32bpp-extra/repository/revisions/0451ecd5cc53 17:24:45 <planetmaker> I'm not sure how much it'd be used and what best would be the way to configure it 17:25:00 <planetmaker> ls 17:25:39 <DJNekkid> there was,iirc, 10 regions 17:25:55 <planetmaker> around that, yes 17:26:52 <DJNekkid> east,west,north(scandinavia),south europe, n/s america, africa, asia, oceania 17:29:17 <DJNekkid> there are balsicly: lots of w-europe, pretty many e-europe, some american(both N and S) and scand, a handfull of asian, and barely african and oceania 17:29:49 <planetmaker> yeah 17:30:07 <planetmaker> I wonder whether one could make a switch for each of the major countries 17:30:59 <DJNekkid> hmm 17:31:07 <Ammler> why should someone reduce those per parameter? 17:31:17 <Ammler> is that a ttdp feature? 17:32:31 <DJNekkid> huh? 17:33:24 <planetmaker> Ammler, scenario designers 17:34:08 <Ammler> DJNekkid: it isn't worth imo 17:35:37 <DJNekkid> worth it? 17:35:45 <DJNekkid> its a VERY easy feature to introduce 17:36:47 <Ammler> rather send the time to balance the set with ukrs/nars/dbset/jptrains... 17:37:14 <Ammler> I would prefer moar, not leass 17:37:22 <DJNekkid> agreed :D 17:37:59 <DJNekkid> balance in what way? 17:38:09 <DJNekkid> capacities? 17:38:13 <DJNekkid> running costs? 17:38:17 <Ammler> prcies 17:38:25 <Ammler> so someone can compete with 2cc against dbset 17:39:02 <Ammler> maybe someone will ever make a "set" filter :-) 17:40:11 <DJNekkid> well, i prefer to have the default costs quite high 17:40:26 <Terkhen> hmmm... I think I could remove #defines from language files in FIRS doing something similar to that write_undef.diff 17:40:52 <DJNekkid> but the two new parameters should be able to balance it out quite well... 17:41:01 <DJNekkid> with separate purchase and running costs 17:41:08 <Ammler> DJNekkid: yes, but if I enable the "make compatible with dbset", the prices for a ICE sould be the same on both sets 17:42:51 <DJNekkid> like "excatly" the same? 17:43:06 <DJNekkid> currently an ICE3 p-cost is aprox 1/2 of db-set 17:43:46 <Ammler> well, just an example :-) 17:45:36 <Brot6> #openttdcoop Server Patch Pack - Revision 5:389faaca98bf: Change: enalbe automatic release building (Ammler) @ http://dev.openttdcoop.org/projects/serverpatches/repository/revisions/389faaca98bf 17:55:29 *** Seberoth has joined #openttdcoop.devzone 18:23:57 *** Alberth has joined #openttdcoop.devzone 18:31:31 *** Seberoth has quit IRC 18:31:41 *** Seberoth has joined #openttdcoop.devzone 18:53:48 *** Seberoth has quit IRC 18:58:14 *** Seberoth has joined #openttdcoop.devzone 19:05:56 <Brot6> OpenGFX - Revision 521:68c1706adbc3: Change #1263: Slightly different colour for one of the rough... (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/68c1706adbc3 19:09:42 <Brot6> OpenGFX - Feature #1263: Toyland Rough Land (planetmaker) @ http://dev.openttdcoop.org/issues/1263#change-3723 19:46:34 <Brot6> OpenGFX - Revision 522:5951f28fa639: Fix #1392 (r513): Build the documentation files and bundle t... (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/5951f28fa639 19:49:38 <Brot6> Example NewGRF Project - Bug #1392 (Closed): make builds no docs (.txt) files anymore (Ammler) @ http://dev.openttdcoop.org/issues/1392 19:49:38 <Brot6> Example NewGRF Project - Revision 173:0b9a54a4efc1: Fix #1392: Build and bundle the documentation... (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/0b9a54a4efc1 19:49:38 <Brot6> Example NewGRF Project - Bug #1392 (Closed): make builds no docs (.txt) files anymore (planetmaker) @ http://dev.openttdcoop.org/issues/1392#change-3724 20:06:25 <Brot6> OpenGFX - Feature #942: Profit icons are too similar to "moving" icon (frosch) @ http://dev.openttdcoop.org/issues/942#change-3725 20:14:43 <Hirundo> "If xoffs is negative, yoffs must be one lower than the wanted value." <- Yet Another Nfo Quirk :o 20:16:10 <frosch> :p 20:17:26 <planetmaker> what?! 20:17:30 <planetmaker> that's evil 20:21:20 <Brot6> #openttdcoop Server Patch Pack - Bug #1393 (New): 78 (compiler) @ http://dev.openttdcoop.org/issues/1393 20:22:57 <Brot6> Autopilot - Revision 82:506bc7916258: Change: content_download to ignore (Ammler) @ http://dev.openttdcoop.org/projects/autopilot/repository/revisions/506bc7916258 20:30:04 <Hirundo> I doubt that OpenTTD implements YANQ correctly, as I've found no trace of it in the code 20:31:48 <Yexo> Hirundo: which action/feature is that? 20:32:10 <Hirundo> both airports and industries 20:32:22 <Hirundo> tile layout, for type = 0xFF 20:34:50 <planetmaker> Hirundo, wth is that, YANQ? 20:34:59 <Yexo> <- Yet Another Nfo Quirk :o 20:35:06 <planetmaker> :-D loool 20:35:22 <Yexo> I can't find a trace of openttd implementing that either 20:35:56 <Yexo> I did find out that a newgrf can cause an index out of bounds by copying the layout of a non-existing industry 20:38:55 <Hirundo> Does anyone know of a station grf that allows building a station that has both 'rail' and 'non-rail' tiles in one unit? 20:38:57 <Rubidium> Hirundo: I hope they explained my idea adequately, if not please say so 20:39:07 <Rubidium> (my idea = the NML thing from hours ago) 20:40:24 <Hirundo> defining 32bpp[normal|EZ] sprites in NML and generating the correct pngs/offsets should be possible 20:47:23 <planetmaker> please let that rather be additions for > 0.1 :-P 20:47:27 <Yexo> http://pastebin.ca/1931385 Any comments on this syntax? 20:49:29 <Hirundo> How does this work for spritesets? 20:50:15 <planetmaker> Yexo, that doesn't seem consistent 20:50:23 <planetmaker> usual way to do seems to be 20:50:42 <Yexo> http://pastebin.ca/1931388 like that? 20:50:48 <Yexo> ^^ for Hirundo 20:50:49 <planetmaker> block_type (name, parameters) { ... } 20:51:28 <Hirundo> That makes spritesets global 20:51:44 <Yexo> aren't they already global? 20:52:47 *** Alberth has left #openttdcoop.devzone 20:52:53 <Hirundo> They are currently per-spriteblock 20:53:22 <planetmaker> hm, I withdraw my last comment 20:53:30 <Yexo> I didn't know that 20:53:35 <Hirundo> At least in code, the documentation probably doesn't contain such subtleties 20:53:44 <planetmaker> Synatx is fine with me 20:54:41 <Hirundo> Does it allow defining 32bpp sprites without 8bpp ? 20:54:51 <Yexo> Hirundo: in that case we could just force the alternative_graphics block also in the spriteblock-block 20:54:58 <Yexo> no, it doens't 20:55:08 <Yexo> but it doesn't need to, because a newgrf always needs 8bpp sprites 20:56:08 <Hirundo> Allowing that might be nice for the 32bbp guys who work on base sprites 20:57:06 <Yexo> that doesn't work, nml is meant to write a grf as output 20:57:20 <Yexo> it's not a 32bpp graphics development tool 20:57:51 <Yexo> but just replacing the name by the sprite number allows it, so it's no problem for the syntax 21:00:00 <GT> Yexo, are the offsets in the file and the size needed? They have to be split in seperate pngs anyways 21:00:20 <Hirundo> nml could do that for you 21:00:29 <Yexo> They have to be split in seperate pngs anyways <- there is no reason to split them, nml can do that 21:00:56 <Hirundo> We could also allow 0,0,0,0 as xpos/ypos/xsize/ysize and take that to mean 'entire image file' 21:01:11 <Yexo> if you define a template you can reuse that 21:01:45 <Hirundo> Can airports have more than 1 layout per rotation ? 21:02:09 <Yexo> yes 21:02:21 <Yexo> airports can have multiple layouts, and each layout has a rotation-property 21:02:57 <GT> most artists generate a single or multiple pngs, and pngcodec that, having to merge the pngs to a single file, define the offset and size in nml would mean extra work compared to current situation. So the 0,0,0,0 Hirundo proposes would be nice 21:03:01 <Yexo> so it can also be used to seperate between a modern and old look 21:03:45 <Yexo> 0,0 meaning "complete file" is fine by me 21:04:23 <Yexo> GT: mind that pngcodec is no longer needed because nml will do that part 21:04:49 <GT> of course, I was refering to the current way of working 21:05:10 <GT> where you only need to specify the ingame ofsett with pngcodec 21:05:40 <Brot6> NewGRF Meta Language - Feature #1394 (New): tile layouts (Hirundo) @ http://dev.openttdcoop.org/issues/1394 21:05:42 <GT> so the nml replacement ideally would only need that same data, 21:06:03 <GT> which would be accomplished with the 0,0,0,0 syntax 21:06:31 <Hirundo> To what extent are the offsets for buildings standard, or at least dictated by a formula? 21:07:01 <Yexo> what i meant is that if you create a 32bpp png file with all the sprite in the same locations/sizes, the offsets can be reused, resulting in for example this: http://pastebin.ca/1931394 21:10:14 <planetmaker> Hirundo, the x offset usually is -31, if they take the full width. If it's smaller... well 21:10:25 <planetmaker> And the height gives you an indicator for the y-offset 21:10:52 <planetmaker> like 0-(height-31) or similar 21:11:39 <GT> Yexo:sound very nice, I was just reluctant to have to add the offset and size always, even when using single sprites per tar. 21:11:54 <GT> s/tar/png/ 21:12:21 <Yexo> I can understant that, but with Hirundo proposal to use 0,0 that shouldn't be a problem, right? 21:12:28 <GT> right 21:13:38 <GT> so if that is added, it offers extra possibilities for templating, and no extra work for single sprite pngs, so that sound about how we want it 21:13:50 <GT> it = nml 21:14:24 <Yexo> only thing it doesn't support is coding sprites without a grf, so for the basesets you'll still have to use pngcodec (or we need to find a solution for that in nml too) 21:16:16 <GT> there are no sprites without a grf, so define the basesets in nml, and you're fine :) 21:19:27 <Yexo> yep :) 21:21:33 <planetmaker> :-) 21:22:29 <planetmaker> he. That'll give extra incentive to convert OpenGFX quickly to NML once we have a release 21:22:49 <planetmaker> Unfortunately I cannot do that without a release... Packagers would jump my throats ;-) 21:22:52 <GT> pm: I did some experiments with loading the 32bpp_extra.grf at game startup, but not a lot of success 21:23:02 <planetmaker> hm :-( 21:23:24 <planetmaker> not a lot success means: it didn't load or it didn't resolve the issue even if loaded? 21:23:43 <GT> ripping out the actions 3 makes the grf safe for static use, but it is not used at game start screen 21:23:59 <planetmaker> oh, drat 21:25:01 <GT> so the only way I've found so far, is to define a 32bpp.obg file ( a copy of opengfx.obg), and replacing the ogfxe_extra with 32bpp_extra.grf 21:25:46 <GT> defining a grfid starting with FF, or even completely ffffffff did not work 21:26:43 <Brot6> OpenGFX - Revision 523:0b11ace3e9a3: Feature: GUI sprites for vehicle profits, new news messages ... (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/0b11ace3e9a3 21:26:50 <GT> did not work: ffffffff gave an error (system grf), start with ff did not solve the issue 21:27:00 <planetmaker> well. Of course defining the GRFID alone doesn't help. You need to tell OpenTTD also to always load it like a base set grf 21:27:29 <GT> yes, and that worked, when defined in the obg file 21:28:03 <planetmaker> Yes. My suggestion is: kinda recognize it as a base grf always. Additionally to the existing one 21:28:37 <planetmaker> But... Might be more trouble than it's worth 21:28:56 <planetmaker> And defining a separate base set might not be the worst idea; actually it might be the most logical one 21:30:06 <GT> not really a lot of trouble, more a logistic problem: take ogfx base set, and replace ogfxe_extra with 32bpp_extra. 21:30:25 <planetmaker> hm yes. What's the difference of those files? 21:30:43 <Brot6> NFORenum - Revision 485:5a0cf83e3c0e: Update: Action 5 type 15 has A0 sprites now. (frosch) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/5a0cf83e3c0e 21:30:52 <Rubidium> yay :) 21:30:56 <planetmaker> :-) 21:31:04 <GT> no colortables, and basically fixed numbering (which even might be solved with nml) 21:31:06 <planetmaker> Next nightly will compile fine again :-) 21:31:15 <planetmaker> fixed numbering? 21:31:40 <planetmaker> Well, that's what I offered a lot of times: we keep the numbers fixed :-) 21:31:56 <planetmaker> Unless there are new GUI sprites. But then all things need an update anyway 21:32:07 <GT> yes, but not in sync with original graphics 21:32:29 <planetmaker> that's not possible 21:32:44 <GT> so a seperate grf to base the 32bpp sprite numbers upon is still the best option to keep things working 21:32:47 <Rubidium> planetmaker: you can't keep the numbers fixed 21:33:00 <Rubidium> whenever we need another action15 type you're basically screwed 21:33:01 <GT> for both groups of users: ogfx and original graphics 21:33:18 <Rubidium> either you add it at the end and the next time a GUI sprite is added you get into trouble 21:33:19 <planetmaker> yes and yes 21:33:30 <Rubidium> or you add it before the GUI sprites and you're already in trouble 21:34:02 <frosch> nml could also generate a 8bpp fallback from the 32bpp stuff, e.g. greyscale or so 21:34:28 <frosch> or black with red text "activate 32bpp blitter" :p 21:34:34 <planetmaker> :-D 21:34:48 <GT> so the only problem now is that is has to be loaded at game start, so the coast line is correct in the initial screen already. 21:35:05 <planetmaker> Btw, your crown will be shown irrespective of base set, frosch :-) 21:35:14 <frosch> yeah, noticed that :) 21:35:34 <planetmaker> and thanks for the quick patch / feature :-) 21:36:28 <frosch> well, it took a bit longer, as it continues from the wrong backup or so... 21:37:15 <frosch> night though :) 21:37:20 <Rubidium> night frosch 21:37:20 <GT> best option would be to have a bundle with the ogfx base set, and replace the ogfxe_extra with 32bpp_extra and a separate obg file. Would take no more than some scripting on the openttdcoop server I guess 21:37:22 *** frosch has quit IRC 21:37:49 * Rubidium wonders how bad it is to add a third palette "3", which is 32 bits with a DOS paletted fallback 21:41:31 <Brot6> NewGRF Meta Language - Feature #1395 (New): sprite layouts (Hirundo) @ http://dev.openttdcoop.org/issues/1395 21:42:48 <GT> Rubidium: you mean extend the newgrf spec so it can incorporate real 32bpp data? 21:43:43 <GT> I'm also wondering whether it would need to be 40 bits (for the mask file) 21:44:01 <Rubidium> no, just make it a proper base graphics set 21:44:20 <Rubidium> i.e. include your own "version" of opengfx 21:44:37 <Rubidium> it's size effect would be relatively minimal 21:44:59 <Rubidium> and we could consider automatically switching to a 32 bits blitter when selecting that set 21:45:25 <Rubidium> you'd also not need to worry about the sprite numbers in the original graphics and/or OpenGFX 21:45:52 <Rubidium> that's (ofcourse) primarily about the extra GRFs 21:47:40 <GT> Well, that about what I was pondering about about: define a new obg, copy opengfx for the base grf except the extra file, that gets replaced with 32bpp_extra. Automatic activating of the blitter is even better (though the animated one is a pita for 32bpp) 21:50:23 <GT> (replacing some colours with others is not a nice job when using several million of colors) 21:51:41 <Ammler> then I would make a proper branch, which you can from time to time pull 21:51:46 <planetmaker> good night frosch... 21:52:02 <GT> animation could be done with mpng, or proprietary with using multiple sprites per png 21:52:51 <planetmaker> why is the animated one bad for 32bpp? 21:52:53 <Yexo> Rubidium: I fail to see the advantage of that. As long as the 32bpp baseset is incomplete it'll probably use some 8bpp graphics 21:53:00 <planetmaker> nvm 21:54:00 <Yexo> so the "palette" of the 32bpp baseset would need to be set to the palette of those 8bpp graphics anyway 21:54:47 <planetmaker> GT: then one could define the firs 192(?) colours to be subject to palette effects with 32bpp 21:55:05 <planetmaker> maybe my understanding is wrong, but that shouls suffice 21:55:07 <planetmaker> *should 21:55:42 <Rubidium> Yexo: it will always use some non-32bpp graphics, but having a way to automagically select the blitter and not having to worry about sprite numbers in the original graphics/opengfx for it to work right is probably quite beneficial 21:56:46 <Yexo> I agree about that part, but then it probably needs 2 new pallete entries "3: 32bpp with dos-paletted substitute, 4: 32bpp with windows-paletted substitute" 21:57:08 <Brot6> serverpatches: update from to r20690 done (7 errors) - http://bundles.openttdcoop.org/serverpatches/releases/r20690 21:58:31 <planetmaker> Yexo: that should not be needed 21:58:56 <Rubidium> or maybe just another field telling it's 32 bpp :) 21:59:04 <Rubidium> blitter? :) 21:59:07 <planetmaker> One substitute palette should be enough as you would need to define the 8bpp fallback sprites anyway 21:59:16 *** ODM has quit IRC 21:59:38 <Yexo> separate field might be better 21:59:50 <Yexo> and that's also completely backwards compatible 22:06:54 <GT> pm: the problem is that 32bpp sprites are not limited to 255 colours. Palettes are an 8bpp concept. If you limit animation to 192 colours, you're effectively back to 8bpp. Eg the water waves: you cannot select a couple of colors from all the blue gradients, and replace them with something else, and still have a nice 32bpp wave 22:07:51 <planetmaker> GT: you're saying you can't have a nice wave with 192 different colours? 22:08:32 <GT> how many of them are blue variants? 22:08:37 <planetmaker> all 22:08:57 <planetmaker> in that case :-) 22:09:30 <planetmaker> That's where the 32bpp "palette" could be different. 22:09:46 <planetmaker> it doesn't need a palette as 32bpp has all colours 22:10:06 <planetmaker> But you have a palette anyway. So you could use that for re-colour and animation purposes 22:10:28 <planetmaker> setting it for the sprite as you need it 22:10:44 <planetmaker> well... probably don't mind me there, though :-) 22:12:13 <GT> well, I have to give it some thought, but with the mask files, and code we have now, it is not possible imo to have nice 32bpp animation 22:21:23 <planetmaker> hm, yeah 22:27:04 <GT> btw, recolour is already taken care of in the EZ patch, by using a blending algorithm that blends the original sprite colour with the colour of the mask, which gives a much better result than just replacing the company colours with the 8bpp mask file pixes as in trunk 22:27:59 <Yexo> if you can split off that part of the code that might be considered for inclusing in trunk already 22:28:14 <Yexo> because if I understood you correctly that's separate from ez 22:30:32 <GT> yes, the ez-patch definately needs a split up: there is zoom-in, real transparency (also for shadows), larger company manager faces, interpolation for zoom out instead of cutting out half the pixels, cc recolour, spritecache for every zoom level 22:31:49 <Ammler> GT, the devzone now would support building the patch queue 22:32:02 <Ammler> like I just tested with the server patch pack 22:32:13 <GT> I saw: add an mq dir to the .devzone 22:32:24 <Ammler> http://bundles.openttdcoop.org/serverpatches/releases/r20690/ 22:32:28 <GT> Would that also support nightly builds 22:32:31 <GT> ? 22:32:50 <Ammler> it is kinda prepared to support a "testing" 22:32:57 <Ammler> but I need to finish that 22:33:33 <Ammler> currently, you just need to tag the patch queue with the hash it applies 22:33:37 <Brot6> OpenGFX - Feature #942: Profit icons are too similar to "moving" icon (planetmaker) @ http://dev.openttdcoop.org/issues/942#change-3726 22:33:54 <Ammler> then it creates the hg repo for qclone or clone 22:34:23 <Ammler> http://hg.openttdcoop.org/serverpatches -> http://hg.openttdcoop.org/serverpatches.mq 22:34:56 <Ammler> clone would be needed for the CF 22:35:01 <Ammler> qlcone for others 22:35:41 <planetmaker> [00:27] <GT> btw, recolour is already taken care of in the EZ patch, by using a blending algorithm that blends the original sprite colour with the colour of the mask, which gives a much better result than just replacing the company colours with the 8bpp mask file pixes as in trunk <-- nice :-) 22:36:08 <planetmaker> isn't it an idea to use something like that for animation: changing the recolour map periodically? 22:36:15 <GT> That would be a big improvement, as windows support for the ez patch is frequently asked for, and I dont make windows bins anymore since my virusscanner decided that msys is dangerous and should not be started. 22:36:34 <planetmaker> :-D 22:36:59 <Ammler> well, I do make the build just for a "automatic" test, if it works 22:37:51 <Ammler> GT for enabling the tag building .devzone/build/releases/enable 22:37:56 <Ammler> just touch 22:38:11 <GT> releases or nightly? 22:38:30 <Ammler> how would you like to build nightly? 22:38:31 <GT> since I've never made a release 22:38:55 <Ammler> well, the release in this case is just a "fixed" revision 22:39:08 <Ammler> it's not openttd stable :-) 22:39:54 <GT> so, create the enable file, create the mq dir and tag the patch queue should do the trick? 22:40:17 <planetmaker> yes 22:40:54 <Ammler> the tag name should be the hash of the "reviewed" openttd trunk.hg 22:41:10 <GT> Nice, that is surely going to go on my already overloaded todo list 22:42:22 <Ammler> just check the serverpatches repo as example 22:42:28 <GT> full hash or "short" hash 22:42:42 <GT> Ammler: certainly will do 22:43:17 <Ammler> I don't think, that matters 22:43:35 <Ammler> just don't use the rev, as the trunk.hg differs from the devzone clone of it 22:44:10 <GT> OK, seems logical 22:44:32 <GT> Shit, if only I had lots of spare time 22:44:35 <Ammler> maybe we could use the svn rev number 22:44:43 <Ammler> might look nicer 22:44:54 <Yexo> that's not unique 22:45:01 <GT> Not? 22:45:08 <Ammler> Yexo: how is that possible? 22:45:28 <Yexo> if GT has two different patch versions for the same svn version, the svn versino alone is not enough to identify which one was used 22:45:55 <Ammler> Yexo: same would happen with the hash 22:46:31 <Ammler> we do not talk about the hash of the patch commit 22:46:54 <Ammler> what I need to know is the parent 22:47:04 <Ammler> which is the same as svn rev or hash 22:47:17 <GT> wouldn't the hash be used for the upstream checkout, combined with the latest version of the patch queue? 22:48:18 <Ammler> hmm? 22:48:20 <GT> (which about is what Ammler typed faster than me) :) 22:50:45 <Yexo> Ammler: ah, I didn't know you were talking about the hash of the parent repo 22:50:51 <Yexo> in that case the svn rev can be used as well 22:59:13 <Ammler> the patches do also have a Parent 22:59:44 <Ammler> but what to do if there are more patches with different parents 23:14:25 <GT> The parent of a patch can refer to a hash in a local repo, so I dont think it is needed to check that, the correct hash of the upstream repo should be the responsibility of the patch queue writer. 23:14:54 <GT> as indicated by the tag 23:16:22 <GT> unless Im wrong about the parent is pointing to the hash of the repo it is created in 23:17:45 <planetmaker> yes and no. parent is always the previous rev. That may be the previous patch in a queue 23:21:05 <Brot6> repository /home/ottdc/hg-repos/clientpatches registered in Redmine with url /home/ottdc/hg-repos/clientpatches 23:21:05 <Brot6> repository /home/ottdc/hg-repos/clientpatches created 23:21:14 <GT> in that case every patch in a series will have a different parent, even more argument to not check. 23:21:23 <Ammler> GT, the mq patch has the parent in it's header 23:21:35 <Ammler> the parent hash of the repo it is applied to 23:22:27 <GT> Ok, so the parent is pointing to the main repo, and not to the previous rev in the patch queue? 23:23:06 <GT> the main repo may be local, so also not available in the remote repo 23:24:52 <GT> The way I see it, the complete patch stack is compatible with a certain version of the main (remote) upstream repo, and that one should be tagged. 23:25:26 <Ammler> GT a mq is not always a repo 23:25:26 <GT> IE, the queue should be tagged with that rev 23:26:46 <GT> No, but in that case the mq certainly is local 23:27:03 <Ammler> # Parent 930fc651306cd28401c4a4c722d577edf5cf3407 23:27:24 <Ammler> and that hash, you find in the mainrepo 23:27:30 <Ammler> not in the mq repo 23:27:55 <Ammler> and that does tell you to which hash the patch is "refreshed" 23:29:57 <GT> yes, clear, but then the patch queue maintainer knows to which rev the main repo and the patch stack is updated to, and he should tag the queue with that rev. 23:30:34 <Brot6> #openttdcoop Client Patch Pack - Revision 6:5da8dc01dc23: Added tag r20145 for changeset 9005c0c5... (Ammler) @ http://dev.openttdcoop.org/projects/clientpatches/repository/revisions/5da8dc01dc23 23:31:19 <Ammler> that should now create a clientpatches.mq repo and apply those patches 23:33:41 <Brot6> #openttdcoop Client Patch Pack - Revision 7:fc25643a7a0c: Change: enable release building (Ammler) @ http://dev.openttdcoop.org/projects/clientpatches/repository/revisions/fc25643a7a0c 23:35:21 <Brot6> #openttdcoop Client Patch Pack - Bug #1396 (New): 78 (compiler) @ http://dev.openttdcoop.org/issues/1396 23:37:07 <Brot6> Autopilot - Revision 84:291b51f5d8d5: Feature: configurable endargs to the command (Ammler) @ http://dev.openttdcoop.org/projects/autopilot/repository/revisions/291b51f5d8d5 23:37:25 *** thgergo has quit IRC 23:40:39 *** Westie has quit IRC 23:42:47 <GT> Well, time to sleep, cu soon 23:43:11 <GT> bye 23:44:41 *** GT has left #openttdcoop.devzone 23:48:45 *** KenjiE20 has quit IRC 23:49:46 *** Westie has joined #openttdcoop.devzone 23:54:41 <Brot6> clientpatches: compile of r20145 still failed (#1396) - http://bundles.openttdcoop.org/clientpatches/releases/ERROR/r20145