Times are UTC Toggle Colours
09:52:06 *** Alberth has joined #openttdcoop.devzone 10:47:39 <DevZone> Project World Airliner Set build #698-push: FAILURE in 1 min 0 sec: https://jenkins.openttdcoop.org/job/worldairlinersset/698/ 10:50:24 <DevZone> Yippee, build fixed! 10:50:25 <DevZone> Project World Airliner Set build #699-push: FIXED in 2 min 44 sec: https://jenkins.openttdcoop.org/job/worldairlinersset/699/ 11:14:04 *** oskari89 has joined #openttdcoop.devzone 12:32:31 *** Supercheese is now known as Guest634 12:32:35 *** Supercheese has joined #openttdcoop.devzone 12:37:18 *** Guest634 has quit IRC 12:51:28 *** frosch123 has joined #openttdcoop.devzone 12:54:22 *** oskari89 has quit IRC 15:37:35 *** Elyon has quit IRC 16:48:45 <DevZone> Project ecs build #75-push: SUCCESS in 32 sec: https://jenkins.openttdcoop.org/job/ecs/75/ 16:49:53 <DevZone> Project 2ccts build #371-push: SUCCESS in 1 min 43 sec: https://jenkins.openttdcoop.org/job/2ccts/371/ 17:04:34 *** Taede has quit IRC 17:08:11 *** Taede has joined #openttdcoop.devzone 18:20:23 *** Elyon has joined #openttdcoop.devzone 18:40:35 <DevZone> Project road-hog build #580-nightlies: SUCCESS in 34 sec: https://jenkins.openttdcoop.org/job/road-hog/580/ 19:52:53 <Elyon> how do I tell grfcodec (or is it nforenum) that I want Info v32? 19:54:46 <Elyon> trying to add 32bpp stuff, but I get a meaningful error of "Could not read ypos from apparent real sprite", which makes sense as xpos is probably read as "8b" and then "pp" would be read as the ypos 20:02:42 <Alberth> I remember a recent irc discussion where the answer to such a question was -g 2 20:02:59 <Alberth> but I cannot find the discussion any more :( 20:02:59 <Elyon> but that is already set, hmm 20:03:39 <Alberth> why would you have "8bpp" in NFO? 20:03:45 <Elyon> grfcodec -s -e -p 2 -g 2 -c 20:04:07 <Alberth> it means nothing to me :( 20:04:33 <Elyon> according to http://newgrf-specs.tt-wiki.net/wiki/RealSprites#Info_version_32, that's the way to enable the use of 32bpp sprites 20:04:38 <Elyon> defining them as alternatives 20:06:57 <Elyon> but according to the header comment by grfcodec, it is creating an Info version 7 file 20:13:20 <michi_cc> Elyon: Are trying to decompile an existing grf file or editing old NFO sources? 20:14:45 <Elyon> michi_cc: neither 20:14:55 <Elyon> I am making a new NFO-based grf 20:16:00 <michi_cc> Then take the header comment from any other existing file with NFO 32 (can be any decompiled GRF). Just be aware of the different order of the components in the real sprite definition. 20:17:09 <michi_cc> E.g. https://paste.openttdcoop.org/pjymcnynl 20:18:32 <Elyon> is this really the preferred process? I'm using pm's Makefile setup so I'd have to tweak that a bit to make it work automatically ... 20:19:27 <michi_cc> Eh? You have a .nfo (or .pnfo or whatever file), it has to start with these exact lines for a NFO version 32 source. 20:20:17 <Elyon> michi_cc: something in the build setup definitely generates that comment in the generated nfo (from pnfo) file. I had assumed grfcodec generated this comment? 20:20:25 *** gelignite has joined #openttdcoop.devzone 20:22:23 <michi_cc> No. I'd guess there's a header/template file somewhere in the various files of the makefile setup. 20:23:10 <michi_cc> The makefile is using the C preprocessor to combine the pnfo to nfo, there's no grfcodec involved with this step. 20:23:46 <Elyon> yeah, I'm looking through the files now 20:24:13 <Elyon> I just assumed, based on the first line of that comment, that grfcodec generated it - seeing as it actually says that 20:24:14 <frosch123> Elyon: if the sprites are already numbered consecutively in the .nfo, then it was probably run through nforenum 20:24:23 <michi_cc> grep -R 'Info version' * 20:24:50 <Elyon> michi_cc: only the generated .nfo has that 20:25:39 <Elyon> frosch123: they're not numbered, they're commented out with the message "Could not read ypos from apparent real sprite" 20:26:06 <frosch123> so, it was run through nforenum :p 20:26:22 <frosch123> i guess the makefile assumes that nforenum will add the header 20:26:22 <michi_cc> That would be NFORenum then, which probably defaults to NFO version 7 if the input doesn't have the aforemention header. 20:26:29 <frosch123> but that fails for v32 20:26:36 <Elyon> michi_cc: oh, ah, hmm 20:26:41 <frosch123> you have to add the header yourself in the first included nfo file 20:26:41 <Elyon> frosch123: interesting 20:26:49 <Elyon> I'll do that immediately 20:27:34 <michi_cc> I'd add an extra file for the header to make sure you can't accidentally rename it. 20:27:57 <Elyon> rename it? 20:29:51 <michi_cc> Acually, you probably don't need to. Do you have a main file with the different #includes? If yes, the header should probably go there. 20:30:17 <Elyon> I'm using a bit of a different setup, but yes, I have a main file 20:33:23 <Elyon> to which I've added that comment, which is ignored by something and something adds the version 7 instead. I'll look into my build setup, maybe something is wrong there 20:44:44 <Elyon> yeap, nope, can't find anything out of what I would assume to be ordinary. Something is definitely generating that comment, and printing my 'Info v32' comment neatly below sprite 0 20:46:04 <michi_cc> Upload the stuff somewhere? 20:48:12 <Elyon> michi_cc: myes, which of it? The pnfo itself is rather ... long and unwieldy and irrelevant 20:48:23 <Elyon> I'll paste `head -n 50` or something 20:48:30 <Elyon> as well as the errors 20:48:38 <michi_cc> Makefile and associated files more like. 20:48:58 <michi_cc> Your sources are mostly irrelevent. 20:49:03 <Elyon> figures 20:49:42 <michi_cc> Make a zip/tar unless it's some secret stuff :p 20:50:10 <Elyon> it isn't. In fact, it's on dev.openttdcoop.org 20:50:32 <Elyon> well, at least the makefiles I use are 20:50:56 <michi_cc> Yes, but even the default makefile can have/has local modifications. 20:51:23 <Elyon> hmm, I guess 20:51:25 <Elyon> http://dev.openttdcoop.org/projects/cats/repository 20:51:58 <Elyon> ./Makefile and script/Makefile_* seems to be the relevant ones 20:52:19 <Elyon> I just ... I don't know where to look, to be honest, as nothing in the makefiles seems to generate that comment 20:54:32 <Elyon> (the sources there are not the sources I am compiling, by the way - they don't have the header, but I can paste the head of the file I have that does) 20:54:46 <Elyon> I could also zip the lot but it is largely irrelevant 21:03:09 <michi_cc> Ah, it's some interesting interaction between cpp and nforenum. cpp outputs some comments into the source to track the included files, which means the first line in the nfo isn't the first line from the input anymore. And nforenum/grfcodec needs the header starting really at the very first line. 21:03:49 <Elyon> aah, I see 21:03:58 <Elyon> I actually just noticed that the output is a bit odd, myself; 21:04:08 <michi_cc> To fix, add the header to your main pnfo file and modify the file scripts/Makefile_def. It has a line CC_FLAGS = .... Add -P after the -E in the line. 21:05:20 <Elyon> okay that got me somewhere! 21:05:50 <Elyon> or rather, that did indeed seem to fix the issue I was having. Lovely! Thank you! 21:06:02 <Elyon> what does -P do? 21:06:08 <Elyon> purge? 21:07:20 <Elyon> "Inhibit generation of linemarkers in the output from the preprocessor." 21:07:23 <Elyon> I see 21:23:57 <michi_cc> For the record: https://dev.openttdcoop.org/issues/7378 21:25:49 <Elyon> ah, neat 21:25:53 <Alberth> why does nfo tools use that format? 21:54:07 <Rubidium> don't forget the -nostdinc, otherwise gcc 4.9 adds something special for you at the begin as well 21:59:32 *** Alberth has left #openttdcoop.devzone 22:36:06 <michi_cc> Rubidium: That's already in the Makefile project.