Times are UTC Toggle Colours
00:03:57 <SmatZ> good night, planetmaker :) 01:01:07 <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: execution expired 02:05:29 *** Webster has joined #openttdcoop.devzone 02:18:50 *** thgergo has quit IRC 02:19:08 *** Lakie has quit IRC 02:30:00 *** Levi has quit IRC 06:07:16 <Rubidium> planetmaker: AFAIR the compile farm is able to compile those obese (5 binary) universal binaries 06:07:56 <planetmaker> aye 06:08:29 <planetmaker> I'm wondering whether to change 'universal' to just i386 as it works everywhere on intel or to also include x86_64 06:08:37 <planetmaker> which would somewhat be pointless then 06:09:17 <planetmaker> see the patch I linked in the other universe 06:47:07 <Brot6> 2cc train set - Feature #1726: 81-740 (Voyager1) @ http://dev.openttdcoop.org/issues/1726#change-4440 07:15:32 *** ODM has joined #openttdcoop.devzone 08:33:55 *** andythenorth__ has joined #openttdcoop.devzone 08:46:29 <Brot6> 2cc train set - Feature #1727 (New): NY R44 (Voyager1) @ http://dev.openttdcoop.org/issues/1727 10:22:09 *** Levi has joined #openttdcoop.devzone 10:22:48 *** Levi has left #openttdcoop.devzone 10:22:52 *** Levi has joined #openttdcoop.devzone 10:34:31 *** Levi has quit IRC 10:46:09 *** KenjiE20 has joined #openttdcoop.devzone 11:03:31 <Brot6> 2cc train set - Bug #1724: Some chsnges in USSR engines. (simozzz_AK) @ http://dev.openttdcoop.org/issues/1724#change-4441 11:05:49 <Brot6> 2cc train set - Feature #1727: NY R44 (Voyager1) @ http://dev.openttdcoop.org/issues/1727#change-4442 11:13:23 <Brot6> 2cc train set - Bug #1724: Some chsnges in USSR engines. (Voyager1) @ http://dev.openttdcoop.org/issues/1724#change-4443 11:25:52 <Brot6> 2cc train set - Feature #1726: 81-740 (simozzz_AK) @ http://dev.openttdcoop.org/issues/1726#change-4444 12:00:54 *** Lakie has joined #openttdcoop.devzone 12:13:11 *** Webster has joined #openttdcoop.devzone 13:00:12 * Lakie starts working on an nml bjects tutorial 13:00:58 <Lakie> I just noticed though the reference document seems a bit thin around spritesets, templates and spritegroups. 13:02:19 <planetmaker> all documentation clarifications and extensions welcome :-) 13:02:42 <Lakie> Heh, just means I can't refer to it like I could nfo... 13:03:27 <planetmaker> Just do it in spite of, if you need to :-) 13:03:39 <planetmaker> but... better not, of course ;-) 13:04:21 <Lakie> Heh, well it just means I'll have to explain them better... 13:05:20 <planetmaker> :-P 13:05:50 <Lakie> As not to scare people of nml. ;) 13:06:39 <planetmaker> :-) 13:07:28 <Lakie> its x, y, sx, sy, xoff, yoffs, type? for the array of numbers? 13:07:55 <Lakie> in a spriteset? 13:09:38 <planetmaker> x,y, sizeX, xizeY, offsetX, offsetY 13:09:54 <planetmaker> , encoding 13:09:57 <planetmaker> optionally 13:10:20 <planetmaker> where encoding is what is 3rd in the NFO style, transparency and alike 13:12:53 <planetmaker> btw, did you notice that meanwhile meanwhile both OpenTTD and OpenGFX only use png sprites? 13:38:54 *** Levi has joined #openttdcoop.devzone 13:55:54 * andythenorth__ remembers there are some FIRS translations in the dev thread 13:56:01 <andythenorth__> they shouldn't be forgotten! 13:56:45 <planetmaker> yes. But do you plan to release now? 13:57:50 *** Lakie` has joined #openttdcoop.devzone 14:03:40 *** Lakie has quit IRC 14:04:07 <andythenorth__> planetmaker: no release planned yet 14:06:53 <planetmaker> then there's not much point to update the translations now ;-) 14:07:41 <planetmaker> rather I could use the time to think of *better* translations for some. Though lugo(?) added some improvements IIRC 14:28:15 *** Lakie` is now known as Lakie 14:35:54 <Lakie> I know last ones optional, does it work out if it should be for example a tile compression 09? 14:38:11 <Lakie> So for example, if I had 1 1 09 39 64 -31 -8, and thus [ 1, 1, 64, 39, -31, -8 ], would it detect that the last one should be 09 or would I need to specify that, planetmaker? 14:40:01 <planetmaker> It has no intelligence there, just a default value 14:40:16 <Lakie> so 01 14:40:18 <Lakie> Ok. 14:40:20 <planetmaker> Dunno which, I seem to remember 3, but... 14:40:23 <planetmaker> ok 1 :-) 14:40:58 * Lakie shall just ommit it then for simplicity. 14:41:55 <planetmaker> fair enough. It's part of the sprite set description anyway 14:42:04 <planetmaker> you need not really deal with that 14:42:13 <planetmaker> after all - I usually use templates there anyway ;-) 14:42:24 <planetmaker> (which IMHO is one of the BIG advantages here) 14:42:56 <Lakie> Do templates automatically increment? 14:43:15 <Lakie> Since from my quick play about with it, generally you only get one sprite per spriteset 14:43:21 <Lakie> (for objects) 14:44:58 <planetmaker> increment? 14:45:19 <Lakie> Yeah, well if I define two sets of sprites in the template (offsets etc) 14:45:39 <planetmaker> a template is just an arbitrary number of sprites defined, possibly their alignment and placement modified by parameters 14:45:51 <Lakie> And use them in two sprite sets, will it use the first set of values for the first spriteset and the second set of values for the second spriteset? 14:46:18 <planetmaker> template blubber(x,y) { [0,y, 10, 10, 0, 0] [x, y, 10, 5, 10, 10] } 14:46:44 <planetmaker> Sorry, I still don't get you. A template is just saving you to re-do alignment 14:46:56 <Lakie> Its just otherwise I feel it may be more useful for vehicles than objects, 14:47:17 <planetmaker> depends basically how you arange your real sprites in the graphic files 14:47:33 <Lakie> True 14:47:46 <planetmaker> I still would - for example - always use the same template for a ground tile 14:47:53 <planetmaker> once written, never wrong (or always) 14:48:18 <Lakie> Well, unless you have faked foundations. :) 14:48:58 <Lakie> But, I think I follow, its just so you don't have to retype offets and such? 14:49:22 <planetmaker> Basically 14:49:39 * Lakie ponders if planetmaker should write the description and use for most of the nml tutorial instead. ;) 14:49:46 <planetmaker> :-P 14:50:18 <planetmaker> Well... I wrote the _current_ description of the sprite blocks ;-) 14:50:25 <planetmaker> obviously it's a FAIL ;-) 14:50:30 <Lakie> Heh 14:51:01 <Lakie> Well, from what I understand (limited obiously), spriteblocks are really just containers or a method of grouping for building of action1s 14:51:29 <Lakie> spritesets are the actual sprites, and spritegroups (in my content) are the tile layouts 14:51:36 <planetmaker> Well... there's two things: templates and spriteblocks / sets 14:51:39 <planetmaker> yes 14:51:52 <planetmaker> probably. But I don't know tile layouts ;-) 14:52:01 <Lakie> Meh, they are easy! 14:52:13 <planetmaker> people keep saying that :-) 14:52:39 <planetmaker> I guess they'll remain somewhat slightly shrouded till I actually programme them myself 14:52:46 <planetmaker> Maybe... I should programme another airport 14:52:57 <planetmaker> but I'd need graphics :-( 14:53:50 <Lakie> spritegroup basic_tile { ground { ttdsprite: 1420; } building { ttdsprite: 2632; recolor : 0; xtextent: 16; yextent: 16; zextent: 30; } } 14:53:55 <planetmaker> or start OpenGFX+ Industries. But... that'd be too many projects going on 14:54:00 <Lakie> Not really, tile layouts can use base graphics 14:54:04 <Lakie> As shown above 14:54:07 <planetmaker> :-) 14:54:40 <Lakie> Notably its a lot more readable when on multiple lines... 14:54:52 <planetmaker> sure. But that's easily done in the source 14:54:58 <Lakie> Aye 14:56:18 *** frosch123 has joined #openttdcoop.devzone 14:56:19 <planetmaker> I'm still amazed that I can redefine all rail / monorail and maglev waggons in only 1800 lines of code; including graphics for a lot of cargos 14:56:33 * Lakie figures he should cover grf (thoughthats so basic anyway), tempplate?, spriteblock (um, container?), spriteset, spritegroup, switch and itm... 14:56:46 <Lakie> Hmm.. 14:56:59 <Lakie> I imagine templates help cut out a number of lines? 14:57:29 <planetmaker> they let me cut a lot of lines as I only need to do like half a dozen of alignments 14:57:35 * andythenorth__ is finding nfo / cpp templates are cutting down code a lot 14:57:39 <andythenorth__> especially action 1 blocks 14:57:45 <Lakie> I think in my sample, with comments removed, the nfo was just smaller than the nml... 14:57:56 <planetmaker> that might be 14:58:15 <Lakie> And it is fairly readable. :) 14:58:20 <planetmaker> after all nfo is basically the bytes written down. While in NML (at least I) tend to use longer, speaking names 14:58:30 <Lakie> True 14:58:56 <Lakie> Also to do with styles, I prefer a newline for {, most don't 14:59:35 <planetmaker> Depends ;-) 15:00:17 <Lakie> Heh 15:00:37 <planetmaker> a short sprite group can be one line. But longer... 15:01:06 <Lakie> Well, technically even long ones can be one line... 15:01:20 <Lakie> I imagine one could write the whole nml as a single line? 15:01:22 <Lakie> >_> 15:01:30 <Lakie> Or does it not like that? 15:01:50 <frosch123> manindu has quite long lines after preprocessing 15:02:26 <frosch123> most of it is done via #define macros which use \ in front of nl, which gets removed on preprocessing :) 15:03:36 <frosch123> so even though nml is written in python, nml itself does not care about whitespace :p 15:04:09 <Lakie> Heh, I don't think its reading the films as python but more a tag based language? 15:04:17 <Lakie> films? files* 15:05:04 <frosch123> it being lr(1) parseable is everything what counts :) 15:05:38 <frosch123> to my experience that is the biggest trouble in processing nfo files 15:06:45 <Lakie> lr(1)? 15:07:32 <frosch123> parseable from left to right with single look-ahead token 15:07:44 <frosch123> http://en.wikipedia.org/wiki/LR_parser 15:07:45 <Webster> Title: LR parser - Wikipedia, the free encyclopedia (at en.wikipedia.org) 15:08:34 <frosch123> i.e. you know the meaning of every token in the moment you read it 15:09:12 <Lakie> Ah 15:09:27 <frosch123> which does not hold for nfo. you can read a number, and it may be a byte for pseudosprite, or a spritenumber depending on "*" or "**" or something else following after that 15:09:33 <Lakie> I think the only things which don't follow that would be strings? 15:09:47 <Lakie> I guess. 15:10:24 <Lakie> Well, sprites just have a number, most pseduo sprites have <num> * <length> and wave files have <num> ** or something 15:29:33 *** Lakie has quit IRC 15:34:52 *** Lakie has joined #openttdcoop.devzone 15:43:17 *** ODM has quit IRC 15:45:13 *** Lakie has quit IRC 16:20:15 <Brot6> heqs: update from r471 to r473 done - http://bundles.openttdcoop.org/heqs/nightlies/r473 16:20:39 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r635), 32bpp-extra (r39), ai-admiralai (r71), airportsplus (r64), basecosts (r22), belarusiantowns (r7), comic-houses (r71), firs (r1481), fish (r404), frenchtowns (r4), grfcodec (r785), indonesiantowns (r37), manindu (r5), metrotrackset (r56), newgrf_makefile (r220), nml (r915), nutracks (r117), ogfx-trains (r85), ogfx-trees (r41), opengfx (r553), openmsx (r97), opensfx (r97), 16:20:39 <Brot6> smts (r19), snowlinemod (r45), swedishrails (r187), swisstowns (r20), transrapidtrackset (r15), ttdviewer (r26), ttrs (r23), worldairlinersset (ERROR r666) 16:21:33 <Brot6> indonesiantowns: compile of r37 still failed (#1704) - http://bundles.openttdcoop.org/indonesiantowns/nightlies/ERROR/r37 16:22:16 <Brot6> swisstowns: compile of r20 still failed (#1705) - http://bundles.openttdcoop.org/swisstowns/nightlies/ERROR/r20 16:23:02 <frosch123> oh, worldairlinersset is quite devlish 16:23:09 <Brot6> worldairlinersset: compile of r666 still failed (#1725) - http://bundles.openttdcoop.org/worldairlinersset/nightlies/ERROR/r666 16:45:09 <planetmaker> hehe 16:46:02 <planetmaker> about 5.4146 times more devilish than you :-P 16:49:32 <Brot6> 2cc train set - Feature #1728 (New): NY R1 (Voyager1) @ http://dev.openttdcoop.org/issues/1728 16:49:32 <Brot6> 2cc train set - Feature #1728: NY R1 (Voyager1) @ http://dev.openttdcoop.org/issues/1728#change-4445 17:10:31 *** ODM has joined #openttdcoop.devzone 17:17:55 *** Levi1 has joined #openttdcoop.devzone 17:22:55 *** Levi has quit IRC 17:40:09 *** thgergo has joined #openttdcoop.devzone 18:10:03 <Brot6> 32bpp-ez-patches: update from r21028 to r21038 done - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r21038 18:18:56 <Brot6> clientpatches: update from r21028 to r21038 done - http://bundles.openttdcoop.org/clientpatches/testing/r21038 18:20:07 <Brot6> serverpatches: compile of r21038 still failed (#1658) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r21038 18:38:38 <planetmaker> oh, I read that you _have to_ correct "a few" cargo classes in FIRS, andythenorth__ 18:38:53 <planetmaker> or his majesty's ships won't transport goods 18:39:02 <andythenorth__> I have been talking to our friend 18:39:07 <andythenorth__> goods is actually wrong 18:39:09 <andythenorth__> don't know why 18:39:24 <planetmaker> wrong is a relative term 18:39:40 <planetmaker> it was afaik changed to BETTER reflect refit capabilities 18:39:54 <andythenorth__> "inconsistent with other definitions of goods" 18:40:49 <planetmaker> I know 18:41:31 <andythenorth__> I thought it was a bug? 18:41:34 <andythenorth__> perhaps it's a feature 18:41:38 <andythenorth__> it's lost in the depths of time 18:41:53 <andythenorth__> I'll lend him my ships :) 18:41:59 <andythenorth__> they're at least as good, if not better 18:42:17 <planetmaker> it is not a bug. It was discussed at least two days 18:42:41 <andythenorth__> we should document that somewhere then 18:42:46 <planetmaker> IIRC. But I don't know the single arguments. And they might be differently weighted meanwhile 18:42:49 <andythenorth__> like the endless WDPR debate 18:42:58 <planetmaker> is there a debate about them? 18:43:03 <andythenorth__> no longer 18:45:25 <planetmaker> I've support for them as both, wood chips as well as boards 18:47:17 <andythenorth__> what other classes 'need' changing 18:47:47 <planetmaker> none needs changing 18:48:05 <planetmaker> it will all mess up the current support I built 18:48:30 <andythenorth__> I am quite happy with them as is 18:48:32 <Brot6> FIRS Industry Replacement Set - Revision 1482:c9bb2425726e: Change: documented some stuff on carg... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c9bb2425726e 18:48:37 <planetmaker> so am I 18:49:05 <andythenorth__> cargo sprites are over-rated anyway :P 18:49:45 <planetmaker> not at all ;-) 18:49:59 <planetmaker> OpenGFX+Trains will have special ones for every cargo and wagon ;-) 18:50:11 <planetmaker> though fruit and fruit+vegetables won't be different 18:50:16 <planetmaker> but they don't co-exist anyway 18:50:27 <planetmaker> and similar 18:52:14 <planetmaker> actually I even drew a chemical wagon for it ;-) 18:52:21 <planetmaker> or better: modified 19:09:12 *** andythenorth__ has quit IRC 19:19:24 *** andythenorth_ has joined #openttdcoop.devzone 19:25:09 * andythenorth_ has *full* cargo sprite support for FISH :P 19:25:28 <andythenorth_> but the cargo is covered by hatches, so you never see it :D 19:25:45 <planetmaker> :-P 19:26:06 <planetmaker> hehe. OpenGFX+Trains will feature HEQS vehicles :-) 19:26:28 <planetmaker> something needs to go as vehicles. And farm supplies. They do very well :-) 19:26:30 <planetmaker> If you don't mind 19:27:18 <andythenorth_> GPL :) 19:27:22 <andythenorth_> I don't mind 19:27:28 <andythenorth_> they are quite big though ;) 19:34:11 <planetmaker> well. There's a (new) normal car. But also one farming truck 19:34:16 <planetmaker> So there's a bit variety 19:34:28 <planetmaker> Yes, GPL, but... :-) Asking is nice :-P 19:36:31 <andythenorth_> indeed ;) 19:38:35 <planetmaker> we might try some re-colouring on the vehicles, maybe 19:38:50 <planetmaker> But I'll have to figure that out before anyway. Same for containers 19:39:02 <planetmaker> just because ;-) 19:39:15 <planetmaker> (well, and I need an NML example for recolour sprites) 19:59:15 <andythenorth_> planetmaker: are you using 2cc? 19:59:27 <planetmaker> we will, yes 19:59:45 <andythenorth_> iirc, we decided recolour doesn't work 2cc 20:00:04 <andythenorth_> it was mr. frosch who thought that 20:00:18 <planetmaker> it's either or, yes 20:00:23 <planetmaker> afaik 20:00:29 <andythenorth_> shame 20:00:48 <andythenorth_> I was considering writing a photoshop action to pre-process cargo sprites 20:00:53 <planetmaker> but a wagon carrying a container doesn't need tw colours on the 15 pixels which constitute the wagon itself ;-) 20:00:54 <andythenorth_> but I think it would be fragile 20:02:56 <frosch123> andythenorth_: planetmaker: you would not need any custom recolour sprites if you use one or both of the company colours for cargo/random recolouring 20:03:29 <frosch123> i.e. using cb 2d you can set the two recolour colours to use, while keeping one or none of the company colours 20:03:43 <frosch123> so you could draw the wagon with company colour, and the container with a second randmo colour 20:06:56 <frosch123> hmm, no, i guess i failed at that already last time :p 20:07:25 <frosch123> maybe we should just add another resultvalue to cb 2d to make it more useful 20:07:57 <planetmaker> frosch123: that's the idea with the containers 20:08:25 <planetmaker> random colour with CC for some other parts. 20:08:35 <planetmaker> But I haven't yet looked deeply at the technical aspect 20:10:14 * andythenorth_ wants to be able to remap specific colours on a cb :P 20:11:08 * frosch123 found a bug 20:15:34 <Rubidium> frosch123: how many legs does it have? 20:15:45 <frosch123> one too many 20:20:26 <frosch123> ah, i remember how it worked! action D can read the 2cc colourmap offset which you can then return in cb 2d plus the needed offset 20:24:37 <frosch123> hmm, but.. can you already read patchvariables with nml? 20:25:54 <frosch123> does not look like it 20:30:34 <planetmaker> one can 20:31:12 <planetmaker> if not named, always var[0xB3] or so will work 20:31:45 <frosch123> i doubt that :p 20:32:06 <frosch123> you confuse action679d variables with patch variables 20:33:01 <planetmaker> extra_callback_info1/2? 20:33:16 <frosch123> http://wiki.ttdpatch.net/tiki-index.php?page=ReadingPatchVariables 20:34:02 <planetmaker> nml/docs/reference.html#vars-general 20:34:34 <planetmaker> they should be covered (mostly) 20:35:11 <frosch123> i see only action679d variables, no patch vars 20:35:11 <planetmaker> se rails for example checks for driving side 20:35:40 * andythenorth_ wonders what the internals of a grf look like 20:35:43 <Hirundo> I doubt that patch variables are implemented, but we can work on that :) 20:36:01 <Rubidium> so far lzma2 is usually faster than zlib6 for savegame + download. In one case is was ~1% slower 20:36:02 <Hirundo> http://www.ttdpatch.net/grfcodec/grf.html 20:36:03 <frosch123> Hirundo: planetmaker needs patchvar 11 :) 20:36:15 <Rubidium> and I guess this isn't the right window 20:36:21 <Hirundo> andythenorth_: see link above^^ 20:37:19 <Rubidium> Hirundo: linking that is lame. Just should've said, read the docs in grfcodec's docs directory 20:37:28 <frosch123> andythenorth_: be careful though, the docs are writte by a asm programmer 20:37:32 <andythenorth_> hmm 20:37:53 <andythenorth_> I am trying to work out if we could process graphics to replace colour using grfcodec 20:37:55 <Hirundo> andythenorth_: Read the docs in grfcodec's docs directory. 20:38:13 <Hirundo> why (ab)use grfcodec for that? 20:38:17 <andythenorth_> why not? 20:38:34 <Hirundo> Because I don't use grfcodec to play music either 20:39:15 <andythenorth_> Hirundo: because recolouring cargo sprites manually is very dull :P 20:39:23 <andythenorth_> and a photoshop action to do it reliably is hard 20:40:06 <Hirundo> Is it as simple as applying a recolour sprite? 20:40:20 <Hirundo> ('simple' in coding terms) 20:40:31 <andythenorth_> I don't know 20:41:06 <Rubidium> andythenorth just wants to implement #1403 20:41:06 <Brot6> Rubidium: #1403 is http://dev.openttdcoop.org/issues/show/1403 "GRFCodec - Feature #1403: Replace Animation Colors - #openttdcoop Development Zone" 20:41:39 <andythenorth_> more or less yes 20:41:50 <andythenorth_> a helper app could do it 20:42:07 <andythenorth_> I started trying to understand PIL to see if I could use a colour transform 20:42:47 <andythenorth_> but even if i succeed, it would introduce a very non-standard tool to my sets 20:42:58 <Hirundo> You should switch to nml :) 20:43:28 <andythenorth_> I'll use it for new sets...probably 20:44:02 <andythenorth_> recolor sprites are applied in-game 20:44:03 <andythenorth_> ? 20:45:34 <frosch123> they are applied during drawing, just before writing to the screenbuffer 20:45:48 <andythenorth_> isn't that slow? 20:46:38 <frosch123> compared to what? 20:46:53 <andythenorth_> compared to not doing it :) 20:47:39 <frosch123> well, it is only done when recolouring is needed 20:47:52 * andythenorth_ tries to work out how a recolor sprite could say 'no change' for a given value 20:48:08 <frosch123> i.e. drawing non-recoloured sprites does not look up the identity-recolouring 20:48:21 <frosch123> andythenorth_: recolour to same value 20:48:41 <andythenorth_> but then the 1cc * 2cc problem occurs 20:48:53 <andythenorth_> *many* recolour tables needed 20:49:10 <frosch123> no, only if you want to use non-standard recolourings 20:49:15 <frosch123> like three colours 20:49:39 <andythenorth_> which is what I want to do "| 20:49:41 <andythenorth_> :| 20:49:52 <andythenorth_> four colours to be exact ;) 20:49:52 <frosch123> if you restrict to 1cc plus your own rules for the second cc, you do not need any custom recolouring 20:50:19 <frosch123> four colours? 20:50:38 <frosch123> i know heqs are slightly bigger vehicles, but how do you want to fit four colours on them? 20:50:42 <andythenorth_> most bulk cargos are drawn with four colours 20:50:54 <andythenorth_> (this is all related to recolouring cargos) 20:51:15 *** welshdragon has quit IRC 20:51:24 <frosch123> what do you mean with "drawn with four colours"...? 20:51:59 <andythenorth_> frosch123: you have HEQS checked out? 20:52:18 <frosch123> i pulled yesterday iiirc 20:52:37 <frosch123> at tip again 20:53:06 <andythenorth_> have a look at something like "sprites/graphics/60t_mining_truck.pcx" 20:53:30 <andythenorth_> you'll see how the cargos are done 20:53:57 <frosch123> well, but the cargo has only one colour 20:54:08 <frosch123> and the truck as well 20:54:23 <frosch123> so, that vehicle would work with cb 2d without adding any custom recolourings 20:54:32 <andythenorth_> in the case of HEQS yes true 20:54:41 <andythenorth_> in the case of FISH...not so much :) 20:54:46 <andythenorth_> FISH is fully 2cc 20:54:55 <andythenorth_> so no cargo sprites in FISH 20:55:12 <andythenorth_> as I can't face endless copy-paste-pick-colour-fill :o 20:55:21 <andythenorth_> the code would be trivial 20:55:38 <Hirundo> You can easily generate those sprites, but the number of them might become problematic if you want TTP compatibility 20:55:49 <Hirundo> s/TTP/TTDP 20:55:53 <andythenorth_> that seems to be topic of the week :P 20:56:04 <andythenorth_> I care not at all about TTDP compatibility 20:56:30 <andythenorth_> :) 20:56:50 <Hirundo> Even then, each set of recolor sprites is 65kb of uncompressed memory 20:57:26 <Hirundo> It may be a bit much to do that at runtime, while generating the correct sprites is also possible at compile time 20:57:38 <andythenorth_> seems better to just automate it at compile time 20:57:48 <frosch123> Hirundo: iirc there are not enough spriteslots to load enough recolour sprites 20:58:07 <andythenorth_> I want to figure out a way to take a source png, replace specific colours and append to a file 20:58:18 <Hirundo> how many slots are there? 20:58:41 <frosch123> hmm, actually i am not sure 20:58:43 <Hirundo> The number of needed sprites is n*256, with n being the number of recolour variants 20:59:02 <andythenorth_> it seems...not efficient to do it in run time 20:59:08 <frosch123> it depends which spriterange grm uses 20:59:58 *** welshdragon has joined #openttdcoop.devzone 21:00:37 <frosch123> Hirundo: ignore my comment 21:00:49 <frosch123> there are 12000 free slots 21:01:03 <frosch123> :) 21:01:49 <frosch123> andythenorth_: does a simple java application suffice to apply recolourning to png files? 21:02:09 <frosch123> resp. does java work on your mac? 21:02:14 <andythenorth_> I think so 21:02:19 <andythenorth_> Steve is trying to kill it though 21:02:55 <andythenorth_> http://www.theregister.co.uk/2010/10/22/jobs_on_java_for_mac/ 21:02:56 <Webster> Title: Gosling blows lid off Jobs Java nonsense • The Register (at www.theregister.co.uk) 21:05:36 <andythenorth_> frosch123: would it be a thing I run just once to make a 'final' png spritesheet? 21:05:46 <andythenorth_> or would it be a thing called by make? 21:08:15 <frosch123> how you like, but maintaining one .png and generating the other on make sounds more logical 21:10:15 *** Webster has joined #openttdcoop.devzone 21:10:46 <andythenorth_> we can try it and see :) 21:11:07 <andythenorth_> I guess I meant there would need to be a way for make to pass options to the helper app.... 21:11:14 <andythenorth_> (such as the colour remapping) 21:14:30 *** Guest609 has quit IRC 21:30:07 * andythenorth_ goes to bed 21:32:27 *** andythenorth_ has quit IRC 21:33:40 *** frosch123 has quit IRC 22:00:26 <Brot6> OpenTTD WebConfig - Revision 5:753b5302e66f: Removed weird symbols added by Notepad++ in line 0. (Levi) @ http://dev.openttdcoop.org/projects/ottd-webconfig/repository/revisions/753b5302e66f 22:02:20 <Rubidium> s/weird symbols/BOM/ 22:02:43 *** Lakie has joined #openttdcoop.devzone 22:02:46 <Levi1> what's BOM? 22:03:05 <Rubidium> Byte order mark 22:03:28 <Rubidium> two bytes to encode what unicode encoding the file has 22:03:45 <Rubidium> (or three in case of UTF8) 22:03:58 <Levi1> ok... the revision was actually to see whether mercurial push works again, but thanks for the explanation :) 22:16:48 <Lakie> Rubidium: I thouhgt UTF-8 only has one order of bytes? 22:17:38 <Lakie> Oh, sorry misread, a 3 byte sequence. :x 22:20:37 *** Webster has joined #openttdcoop.devzone 22:26:05 *** Guest618 has quit IRC 22:29:44 *** Lakie has quit IRC 23:51:58 *** thgergo has quit IRC