Times are UTC Toggle Colours
00:00:18 <Brot6> DevZone Help Center - ttd-newgrf-psp7-dos.pal (planetmaker) @ http://dev.openttdcoop.org/attachments/download/1742/ttd-newgrf-psp7-dos.pal 00:00:18 <Brot6> DevZone Help Center - ttd-newgrf-dos.gpl (planetmaker) @ http://dev.openttdcoop.org/attachments/download/1741/ttd-newgrf-dos.gpl 07:05:30 <Brot6> OpenGFX+ Airports - Feature #3031: Todo for release 0.3.0 (planetmaker) @ http://dev.openttdcoop.org/issues/3031#change-7721 07:06:20 <planetmaker> Ammler, do you have an idea what triggered the two messages of Brot from 2am? 07:45:08 *** mib_ajnjwk has joined #openttdcoop.devzone 07:45:38 <mib_ajnjwk> HI 07:46:22 <planetmaker> hi 07:50:51 <mib_ajnjwk> I was wondering if someone could give me a hand on a Problem I have. I need a guide on How to change teh properties of Vehicles in a newgrf file 07:52:18 <Hirundo> Guide can be found here: http://www.tt-wiki.net/wiki/NMLTutorial 07:55:34 *** ODM has joined #openttdcoop.devzone 08:04:25 <mib_ajnjwk> thanks 08:04:52 <mib_ajnjwk> Still try to figure ot how to create a nml from a nfo 08:05:24 <planetmaker> that doesn't exist in a releasable, automated way 08:06:08 <planetmaker> you might sweet-talk yexo to convert something for you; you'll have to do a lot of cleanup afterwards (e.g. nice naming and stuff) 08:06:22 <planetmaker> but maybe that code meanwhile doesn't work anymore properly due to certain changes in NML... dunno 08:06:45 <mib_ajnjwk> oh, ok! So, there is noch easy way in extracting a grf file, changing for example a view starting dates for vehicles and compiling them again? 08:07:02 <planetmaker> (I hope Yexo doesn't mind talking about the existance of such draft ;-) ) 08:07:14 <planetmaker> no, that doesn't exist. 08:07:31 <planetmaker> But what you can do is write an add-on NewGRF which modifies properties of vehicles defined in another NewGRF 08:07:39 <planetmaker> as such you don't need to de-compile anything 08:07:56 <Hirundo> the state of the NFO->NML converter is quite interesting... it's known to exist but no-one has ever seen it :) 08:08:08 <mib_ajnjwk> lol 08:08:09 <planetmaker> ^ quantum code ;-) 08:08:57 <Hirundo> though arguably, decompilers may be harder to write than compilers 08:08:59 <mib_ajnjwk> ok, one last question, then I won't bugger you again.... soon :-) 08:09:08 <planetmaker> I wonder whether it could be attached to some long-term issue in NML 08:09:12 <planetmaker> yes, de-compiler... 08:09:17 <mib_ajnjwk> Are there any guid on how to create those extensions? 08:09:32 <mib_ajnjwk> Mentioned above 08:09:53 <Hirundo> You'll need an engine_override(..) in NML 08:10:53 <Hirundo> bbl 08:11:35 <planetmaker> http://newgrf-specs.tt-wiki.net/wiki/NML:Overriding_vehicles_in_other_NewGRFs 08:12:12 <planetmaker> small sidenote: works only in OpenTTD, not in TTDPatch 08:13:19 <planetmaker> then you subsequently (re-)define the properties you want with the correct vehicle IDs as found in the target NewGRF you want to override 08:13:52 <planetmaker> make sure you come back to us with the source code of the complete NewGRF - there's no example NewGRF written in NML which does this 08:14:15 <planetmaker> except maybe a regression test or so. dunno 08:14:28 <mib_ajnjwk> Allrigth, that'll do! I'll try it 08:14:35 <mib_ajnjwk> Thanks a lot for your help 08:14:54 <planetmaker> you're welcome 08:15:19 <planetmaker> if you like, request a project on the DevZone - provided you use an open source license :-) 09:56:24 *** andythenorth has joined #openttdcoop.devzone 10:01:13 <Yexo> <Hirundo> the state of the NFO->NML converter is quite interesting... it's known to exist but no-one has ever seen it :) <- I've uploaded the code a few times 10:01:34 <Yexo> the main problem with it is that there are quite some cases where it doesn't work 10:01:51 <Yexo> hence I'm not too happy about releasing it to the general public, as I already know that will lead to lots of bug reports 10:02:26 <Yexo> but no, I don't mind talking about the existance of it, or even trying to decompile some grfs 10:02:32 <Yexo> mib_ajnjwk: which grf are you trying to decode? 10:04:10 <Yexo> Hirundo: http://devs.openttd.org/~yexo/grf2nml.diff <- that patch is from June 18 this year 10:09:18 <Brot6> Central European Train Set - Revision 143:a1c85b0ab15d: make the 16lu wagons visible again (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/a1c85b0ab15d 10:12:47 <Brot6> Central European Train Set - Revision 144:305777fd2f10: remove some now unused files (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/305777fd2f10 10:15:44 *** andythenorth has left #openttdcoop.devzone 10:32:11 <Brot6> FIRS Industry Replacement Set - Revision 2577:bfe1d14d2af2: Codechange: Rename Biorefinery layout... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/bfe1d14d2af2 10:43:20 <planetmaker> btw, Yexo did you risk a look at the "prepare release" diff I added to the related opengfx+airports issue? 10:45:57 <planetmaker> #3031 10:45:57 <Brot6> planetmaker: #3031 is http://dev.openttdcoop.org/issues/show/3031 "OpenGFX+ Airports - Feature #3031: Todo for release 0.3.0 - #openttdcoop Development Zone" 10:52:07 <Yexo> not yet, I missed it 10:52:10 <Yexo> will look now 10:52:50 <Yexo> the credits in readme.txt don't align (tabs vs spaces) 10:53:43 <planetmaker> hmpf 10:55:28 <Yexo> readme files is still biased towards nfo projects: "MinGW/MSys contain the above mentioned programmes (except renum and 10:55:28 <Yexo> 71 10:55:28 <Yexo> grfcodec of course)" 10:56:18 <Yexo> but that's probably a more general issue with the makefile bundle, not specially for this project 10:57:17 <Yexo> imo that can be left, is you fix the credits section it's good enough to release 10:57:18 <planetmaker> well... the makefile bundle doesn't ever patch existing readmes :-) 10:57:37 <Yexo> ah, true 10:58:53 <planetmaker> indeed, I'll leave the description for building now, though... 10:59:07 <Yexo> as version imo 0.3 would be good now 10:59:07 <planetmaker> The makefile bundle indeed _does_ need an update there 10:59:17 <planetmaker> ok, then I just do that :-) 10:59:28 <Yexo> then we can release 1.0 as new version as soon as openttd 1.2 is released and as such the newgrf is supported by stable openttd 11:02:21 <planetmaker> This NewGRF will suffer the same issue as now FIRS and OpenGFX+Landscape have: not suitable for trunk... what min. version should I set? 11:03:18 <Yexo> the minimum version it needs? 11:04:03 <Brot6> OpenGFX+ Airports - Revision 142:5022fcadf0d8: -Prepare: Update documentation and version informa... (planetmaker) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/5022fcadf0d8 11:28:21 <Brot6> OpenGFX+ Airports - Bug #3032 (Confirmed): preview graphics have holes (planetmaker) @ http://dev.openttdcoop.org/issues/3032 11:29:00 <planetmaker> http://dev.openttdcoop.org/attachments/1810/Prenstable_Park_Transport__8th_Mar_2015.png <-- we don't release yet ;-) 11:29:03 <planetmaker> ^ Yexo 11:37:13 <Yexo> strange bug 11:43:28 <Yexo> I can reproduce it, but the graphics in the repo look fine 11:43:38 <Yexo> as does the code 11:43:42 <planetmaker> hm... 11:43:58 <planetmaker> strange. I shall try maybe later today at home 11:44:04 <planetmaker> osx cannot be an excuse ;-) 11:45:01 <planetmaker> might it be a bug with a specific sdl version? 11:45:37 <Yexo> seems unlikely 11:45:48 <Yexo> why would both you and me have it, and only for this specific type of sprites? 11:46:28 <Yexo> to me it seems to be either a very strange bug in nml (but why haven't we seen it before?) or an obscure one in openttd (again, why now?) 11:47:10 <planetmaker> hm... I compiled with nml r1661 12:11:50 <Brot6> Central European Train Set - Revision 145:aed8a43cba02: experimental movement scheme for 16lu veh... (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/aed8a43cba02 12:19:52 <Hirundo> planetmaker: Yexo: Could it be an overflow in the sprite encoder? 12:20:29 <Yexo> it could be, I really have no clue 12:20:43 <Yexo> haven't looked into it either yet 12:22:26 <Hirundo> hmm yes, it seems tile compression overflows after 7f pixels 12:23:32 <planetmaker> @base 16 10 7f 12:23:33 <Webster> planetmaker: 127 12:23:39 <planetmaker> that's tiny 12:24:43 <Hirundo> I don't see where you'd use such wide sprites other than for airport previews 12:25:13 <planetmaker> oh, you mean sprite width? 12:25:34 <planetmaker> object preview 12:25:35 <Hirundo> yes 12:25:36 <Brot6> OpenGFX+ Airports - Bug #3032: preview graphics have holes (planetmaker) @ http://dev.openttdcoop.org/issues/3032#change-7722 12:25:40 <Hirundo> http://paste.openttdcoop.org/show/554/ 12:25:47 <Hirundo> ^ Could you try with this diff? 12:27:46 * planetmaker tries but has slow computer here :-) 12:29:11 <Hirundo> Yexo: Why is sprite width limited to 255? I thought only ysize (num_lines) had such a low limit 12:33:55 <Yexo> hmm, python is using 2.5gb before it's killed (oom) while trying to encode airportsplus 12:35:45 <Yexo> Hirundo: ^^ that is with your patch, without it python "just" using 500mb 12:36:08 <Hirundo> and when compiling a different grf ? 12:38:33 <Yexo> firs: without patch 180mb, with patch the same 12:38:44 *** dnicholls has joined #openttdcoop.devzone 12:40:12 <Yexo> about sprite size: I don't know what the exact limits are 12:41:55 <dnicholls> afternoon all 12:42:40 <Hirundo> IIRC xsize 16 bit, ysize 8 bit 12:43:46 <Yexo> think I found the problem 12:44:59 <Yexo> your patch was correct, but triggered an infinite loop 12:45:08 <Yexo> after fixing that it's correct now 12:45:13 <Brot6> NewGRF Meta Language - Revision 1662:b81b54157472: Fix: overflow with sprites wider than 127px (H... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/b81b54157472 12:46:40 <Yexo> dnicholls: is anything missing before a release of OpenGFX+airports? 12:46:40 <Hirundo> ah great 12:46:50 <Brot6> OpenGFX+ Airports - Bug #3032 (Closed): preview graphics have holes (planetmaker) @ http://dev.openttdcoop.org/issues/3032 12:46:50 <Brot6> OpenGFX+ Airports - Bug #3032 (Closed): preview graphics have holes (yexo) @ http://dev.openttdcoop.org/issues/3032#change-7723 12:49:43 <dnicholls> yexo: I think there's nothing missing 12:50:59 <Yexo> planetmaker: so ok for release? 12:55:51 <Hirundo> Yexo: I can understand the issues with a nfo->nml converter that works in all cases 12:55:58 <Hirundo> What are the main points that don't work? 12:56:29 <Yexo> everytime we have special cases in nml for action0 properties they need special handling in the decompiler too 12:56:39 <planetmaker> you evil BOFH, Hirundo ;-) 12:56:44 <Yexo> skipping actions with action7 / action9 is only partially supported by the decompiler 12:56:47 <planetmaker> You rdos'ed my computer 12:57:16 <Hirundo> My bad :) Don't shoot me!!! 12:57:21 * Yexo was happy my kernel decided to kill python first 12:57:25 <planetmaker> just this time ;-) 12:57:39 <Hirundo> That's what happens when releasing untested code 12:57:44 <planetmaker> hehe :-) 12:59:21 <Yexo> Hirundo: a more general problem: nml supports code like: return sound("some_file.wav"); in switch-blocks 12:59:36 <Yexo> in nfo that is just "return 73;" (for the first sound, second sound would be 74 etc.) 12:59:52 <Yexo> the decompiler has no way of knowing that is should convert the "73" to a soundfile 13:00:07 <Yexo> and it doesn't support named callbacks yet 13:00:16 <Yexo> if that is done, that could solve the sound problem 13:00:42 <Hirundo> Though it depends on having a sane varaction2 structure in nfo 13:00:50 <Yexo> yes 13:01:12 <Yexo> GRM is not yet supported, and neither are patch variables 13:01:35 <Yexo> the latter is problematic since most patch variables are not directly accessible in nml, only parts of them or only after some conversion 13:02:13 <Yexo> some grfs have for example multiple cargo translation tables, which is very problematic for a decompiler 13:02:30 <Hirundo> I guess you could get away with "I'm sorry, I don't understand this patch variable/... on line X." Please fix up later 13:02:40 <Yexo> that is what it currently does 13:02:57 <Yexo> it just prints "TODO_PATCH_VARIABLE" instead of the real variable name 13:03:08 <Hirundo> IMO that's not a big deal, as long as it's documented and/or provides a clear warning 13:04:04 <Yexo> to have somewhat sane nml output it needs to know which constants belong to which properties 13:04:22 <Yexo> ie functions like this: http://paste.openttdcoop.org/show/555/ 13:05:20 <Hirundo> Such information could be useful for the nml->nfo conversion also, to warn if the user does stupid things 13:05:48 <Yexo> yep 13:05:59 <Yexo> actionA is completely ignored currently, although that should be easy to fix 13:06:14 <Yexo> (it's properly ignored, the real sprites are also skipped) 13:06:39 <Yexo> the decompiler doesn't support the more advanced string features 13:07:24 <Hirundo> That's to be expected, as they were added recently 13:07:50 <Yexo> I meant "cases" and "plural" codes 13:08:01 <Yexo> those are not that new anymore 13:08:03 <Hirundo> I'd say it makes sense to add as much as possible to the repository, that way it's much easier to keep up to date 13:08:49 <Yexo> that's true 13:09:18 <Yexo> I'll make a start with adding it bit by bit to the repo, documenting whatever I add in the process 13:09:48 <planetmaker> totally different topic: C++: I have a class derived from a base class which implements a function declared virtual in the base class. Does it matter whether I delcare it (again) virtual in the derived class? 13:10:05 <Yexo> AFAIK not 13:10:30 <Hirundo> no, unless you plan to make a 'derived-derived' class later 13:10:31 <planetmaker> we find in OpenTTD's code both nicely mixed in all places 13:10:46 <planetmaker> ok... so it matters for the "child" 13:12:02 <Yexo> Hirundo: I'd prefer to start after we branch 0.2, so it's clearly separated from that 13:12:21 <Hirundo> agreed 13:14:48 <planetmaker> what stops tagging 0.2.0? 13:15:33 <Yexo> the open issues 13:16:06 <Yexo> those should be the first efforts now, only after that more codechanges / new features 13:16:26 <Yexo> Hirundo: what do you plan for #1395? 13:16:27 <Brot6> Yexo: Hirundo: #1395 is http://dev.openttdcoop.org/issues/show/1395 "NewGRF Meta Language - Feature #1395: sprite layouts - #openttdcoop Development Zone" 13:16:41 <Yexo> all for 0.2 or leave it for now? 13:16:50 <Hirundo> passing a spriteset as a parameter 13:17:03 <Yexo> yes, but that only adds option, it's a new feature that can as well be added later 13:17:24 <Hirundo> I have the initial steps ready, but still no working dev environment nor time to properly set one up :( 13:17:32 <planetmaker> The example projects are not a show-stopper anymore. We have the wiki now 13:17:41 <Yexo> agreed 13:18:09 <Yexo> #1629 and #2933 are show-stoppers 13:18:10 <Brot6> Yexo: #1629 is http://dev.openttdcoop.org/issues/show/1629 "NewGRF Meta Language - Bug #1629: Review conversion for speed property - #openttdcoop Development Zone" 13:18:10 <Brot6> Yexo: #2933 is http://dev.openttdcoop.org/issues/show/2933 "NewGRF Meta Language - Bug #2933: Handling of failed callbacks - #openttdcoop Development Zone" 13:18:44 <Yexo> #2977 is nice-to-have, but not critical imo 13:18:44 <Brot6> Yexo: #2977 is http://dev.openttdcoop.org/issues/show/2977 "NewGRF Meta Language - Feature #2977: town variables - #openttdcoop Development Zone" 13:18:50 <Yexo> on the other hand it should be fairly easy 13:19:33 <Hirundo> ^it takes some time, but you can switch off half of your brain while doing it 13:20:47 <Hirundo> For #1692, you'd need to study all the conversion effects inside nml/openttd 13:20:47 <Brot6> Hirundo: #1692 is http://dev.openttdcoop.org/issues/show/1692 "FIRS Industry Replacement Set - Feature #1692: Why is scrap metal piece goods, not bulk? - #openttdcoop Development Zone" 13:20:58 <Hirundo> err, #1629 13:20:58 <Brot6> Hirundo: err: #1629 is http://dev.openttdcoop.org/issues/show/1629 "NewGRF Meta Language - Bug #1629: Review conversion for speed property - #openttdcoop Development Zone" 13:21:41 <Hirundo> AFAIK rounding of other units was changed from floor() to nearest() in OpenTTD, but speeds were unchanged because of legacy reasons 13:21:57 <Hirundo> therefore, the speed conversion is biased and much worse than others 13:21:58 <Yexo> yes, I have quite a good overview of what happens, but it's hard to come up with a clean way to fix the problem in nml 13:22:15 <Yexo> and yes, speed doesn't round properly in openttd 13:42:12 <dnicholls> planetmaker: typo in readme, my first name is David 13:42:25 <planetmaker> hm, what did I write? 13:42:31 <dnicholls> daniel 13:42:34 <planetmaker> oh :-) 13:42:37 <planetmaker> sorry 13:42:45 <dnicholls> heh :) 14:02:10 *** mib_ajnjwk has quit IRC 14:11:49 <Brot6> OpenGFX+ Airports - Revision 143:5e664675b76c: Fix: typo in readme (yexo) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/5e664675b76c 14:11:55 <Yexo> dnicholls: you want to write a forum post about the release? 14:12:38 <planetmaker> thanks for the fix, Yexo :-) 14:13:00 <Yexo> last call, anything blocking the release before I push the 0.3.0 tag? 14:13:18 <planetmaker> if it works without broken sprites :-) 14:13:37 <planetmaker> let me compile here, too 14:13:56 <Yexo> make sure to pull last nml 14:14:16 <planetmaker> thx 14:14:24 <planetmaker> Yexo: then don't push a tag now 14:14:32 <planetmaker> The CF will use yesterday's nightly otherwise 14:14:43 <Yexo> hmm, right 14:15:07 <dnicholls> yexo: yep I can write something 14:17:51 <Yexo> ok, compiling a new nml nightly first now 14:22:20 <Brot6> nml: update from r1661 to r1662 done - http://bundles.openttdcoop.org/nml/nightlies/r1662 14:23:45 <Yexo> planetmaker: did it work for you too? 14:24:27 <dnicholls> works on my end 14:24:45 * planetmaker should stop trying to multi-task 14:28:05 <planetmaker> other computer, but looks ok to me 14:28:15 <Yexo> ok, here goes :) 14:28:32 <Brot6> OpenGFX+ Airports - Revision 144:210a3c22bd6d: Added tag 0.3.0 for changeset 5e664675b76c (yexo) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/210a3c22bd6d 14:33:22 <Brot6> airportsplus: update from 0.2.1 to 0.3.0 done - http://bundles.openttdcoop.org/airportsplus/releases/0.3.0 14:36:37 <dnicholls> nice work :) 14:37:21 <dnicholls> can anything be done about it being called "Climate dependent airports" on bananas? 14:37:21 <planetmaker> your work! :-) 14:37:57 <planetmaker> hm... I shall take a look. But won't promise anything 14:38:04 <planetmaker> I fear to destroy stuff :-) 14:38:17 <planetmaker> normally the answer is 'no' 14:39:46 <Yexo> that can't be fixed (easily) 14:41:00 <Yexo> planetmaker: I can upload airportsplus-0.3.0.zip from bundles.openttdcoop.org to bananas, right? 14:41:19 <Yexo> dnicholls: the description on bananas can be changed, if you have any suggestions? 14:41:53 <planetmaker> Yexo: that's the savest way, yes. Just upload that zip 14:44:00 <dnicholls> "Adds rotations and climate-dependent graphics for the default airports" might be nicer 14:44:48 <Yexo> done :) 14:45:38 <planetmaker> Yexo: how do you change that? 14:45:56 <planetmaker> or you mean upload? I mean changing name 14:45:56 <Yexo> bananas, manager tab, click "edit", change description 14:46:16 <Yexo> I meant done with updating the description as dnicholls proposed it 14:46:35 <Yexo> I have no clue how to change the name. I've heard it requires manually fixing it in the database 14:46:50 <Yexo> and I don't even have access to the link you posted in the other channel 14:47:08 <planetmaker> oh, the description can be changed during upload, yes 14:47:23 <planetmaker> I thought about the displayed name. Which still is climate dependent airports 14:47:46 <planetmaker> And I don't even find it in our database ;-) 14:47:53 <planetmaker> and I'm scared of the datebase, too :-P 14:47:57 <Yexo> but the displayed name has a direct relationship with the filename 14:48:12 <planetmaker> yes 14:51:05 <dnicholls> if tags can also be edited, would be useful to add opengfx, snow, rotation 14:51:29 <planetmaker> they can 14:51:52 <planetmaker> dnicholls: are you actually interested in updating OpenGFX itself with your updated graphics? 14:52:18 <dnicholls> I would like to :) 14:52:30 * planetmaker too :-) 14:53:37 <planetmaker> It's mostly in nfo, though. But for real sprites that's not that bad... 14:54:14 <dnicholls> nfo can be tamed 14:54:38 <planetmaker> base sets are as tame as nfo can be 14:54:42 <planetmaker> except the rivers ;-) 14:55:27 <planetmaker> ok, I give you access to that repo then, too and you "fix" the airports there, too? 14:56:04 <dnicholls> yes please :) 14:56:21 <planetmaker> great :-) 14:56:28 <planetmaker> done 14:57:17 <planetmaker> when changing sprites: make sure you add or modify credits in docs/authorreview.csv 14:57:31 <planetmaker> it keeps track roughly who drew and modified which sprites 14:57:53 <planetmaker> (and who coded them) 14:58:00 <planetmaker> code = align 14:59:30 <dnicholls> ok will do 15:03:02 <dnicholls> hmm I don't think airportsplus has a release thread. Make a new one or add to the dev thread? 15:03:50 <Yexo> so far it was a bit work in progress, I think with all your new graphics it can have a release thread 15:04:13 <planetmaker> I agree 15:04:31 <planetmaker> it's now definitely a 'full set' 16:18:29 <dnicholls> post done 16:21:23 <Yexo> nice work, and nice screenshots too :) 16:23:15 <dnicholls> would it be possible to have layouts with introduction dates? 16:23:56 <dnicholls> the idea being we could add more "rotations" of the small airport with modern graphics at some point 16:24:37 <Yexo> that is not (yet) possible 16:25:05 <Yexo> you can just add more variations and let the user take care of when he/she builds those 16:26:23 <dnicholls> sounds good 16:27:27 <Ammler> http://www.tt-forums.net/download/file.php?id=149069 <-- why are grass parts of the big airport snowy, some aren't? 16:27:43 <Yexo> the two tiles that are snowy are not part of the airport 16:27:59 <Yexo> the other tiles will have to be made more properly snow-aware at some point 16:31:51 <Ammler> I see 16:37:30 <dnicholls> I suppose we could also have partially snowy graphics for tiles that are one tile below the snowline 16:38:03 <Yexo> yes, planetmaker has done it for firs 16:38:12 <dnicholls> ahh 16:58:39 <Brot6> DictatorAI - Revision 191:104c377e64e2: - Delete the train engine and its wagon when we need an u... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/104c377e64e2 17:07:17 *** frosch123 has joined #openttdcoop.devzone 17:20:03 *** Hanf has joined #openttdcoop.devzone 17:22:25 <Brot6> firs: update from r2574 to r2577 done - http://bundles.openttdcoop.org/firs/nightlies/r2577 17:25:37 <Brot6> cets: update from r140 to r145 done (475 warnings) - http://bundles.openttdcoop.org/cets/nightlies/r145 17:28:07 <Brot6> airportsplus: update from r135 to r144 done - http://bundles.openttdcoop.org/airportsplus/nightlies/r144 17:28:08 <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r252), narvs (r52), bros (r52), ogfx-industries (r123), opengfx (r732), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r640), openmsx (r97), basecosts (r25), nutracks (r208), nml (r1662), water-features (r51), 32bpp-extra (r40), manindu (r7), 17:28:09 <Brot6> newgrf_makefile (r305), ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), dutchroadfurniture (r12), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r110), fish (r684), ogfx-landscape (r85), ttrs (r36), ogfx-trees (r51), swedishrails (r206), grfcodec (r833), ai-aroai (r49), german-townnames (r34), smts (r19), chips (r143), 17:28:12 <Brot6> belarusiantowns (r8), indonesiantowns (r41), ailib-string (r29), comic-houses (r71) 17:46:21 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains, narvs (11 warnings) (Diffsize: 7113), ogfx-industries (1 warnings) (Diffsize: 127939), foobarstramtracks (Diffsize: 11458), manindu (Diffsize: 2), newgrf_makefile, dutchtramset (Diffsize: 25964), swisstowns, dutchroadfurniture (Diffsize: 4509), spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv, ogfx-landscape (1 warnings), swedishrails 17:46:21 <Brot6> (Diffsize: 1350), german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), indonesiantowns (1 warnings) (Diffsize: 1) 18:06:37 *** andythenorth has joined #openttdcoop.devzone 18:55:53 *** andythenorth has quit IRC 18:56:20 *** andythenorth has joined #openttdcoop.devzone 19:06:11 <Brot6> clientpatches: compile of r22896 still failed (#2964) - http://bundles.openttdcoop.org/clientpatches/testing/ERROR/r22896 19:12:11 <Brot6> openttd-vehiclevars: update from r22893 to r22896 done (2 warnings) - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22896 19:13:49 <Brot6> serverpatches: compile of r22896 still failed (#2966) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22896 19:15:46 <Brot6> 32bpp-ez-patches: compile of r22896 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22896 19:32:57 *** Zuu has joined #openttdcoop.devzone 19:33:27 *** Zuu is now known as Guest8990 19:42:12 <andythenorth> Terkhen: did you figure out the FIRS tile templates? :D 20:00:31 *** dnicholls has quit IRC 20:09:56 <Terkhen> andythenorth: no 20:12:02 <andythenorth> :P 20:12:08 * andythenorth has been reading template code 20:12:12 *** Guest8990 is now known as Zuu 20:13:13 <Terkhen> with any success? 20:13:22 <andythenorth> not really 20:13:33 <andythenorth> I don't really understand the aim at the moment 20:13:54 <Terkhen> of what templates? I can explain the spritelayout templates 20:14:08 <andythenorth> yes those 20:14:19 <andythenorth> I can make guesses, but guesses aren't reliable 20:15:04 <Terkhen> check SPRITELAYOUT_NORMAL_BEGIN first 20:15:22 <Terkhen> spritelayout_name is the name that will be used to reference the spritelayout defined by the template 20:15:45 <Terkhen> ground_sprite_normal contains either a ttdsprite number or a spriteset containing the sprite to use for ground 20:15:57 <Terkhen> building_spriteset contains the spriteset with the building sprite 20:16:11 <Terkhen> building_zextent is the value to use for the zextent of the building bounding box 20:16:23 <Terkhen> the template starts a spritelayout block 20:16:35 <Terkhen> the ground block inside it defines the ground sprite 20:16:50 <Terkhen> ignore that LOAD_TEMP stuff for now :P 20:17:05 <Terkhen> treat it as if it was "sprite: GROUNDSPRITE_NORMAL;" 20:17:25 <Terkhen> which contains the "normal" ground sprite for the current climate 20:17:37 <andythenorth> hmm 20:17:44 <Terkhen> everything right for now? :P 20:17:45 <andythenorth> so SPRITELAYOUT_NORMAL chains a call to SPRITELAYOUT_NORMAL_BEGIN? 20:17:51 <Terkhen> yes 20:17:58 <Terkhen> SPRITELAYOUT_NORMAL_BEGIN can be used as a block 20:18:03 <Terkhen> it is a template missing the ending "}" 20:18:37 <Terkhen> so you can do stuff like this: http://paste.openttdcoop.org/show/558/ 20:19:04 <Terkhen> you can define additional buildings and so on inside the template, and then close it 20:19:21 <Terkhen> kind of messy, but it saves creating a thousand templates :) 20:20:11 <andythenorth> right 20:20:13 <andythenorth> ok 20:20:51 <Terkhen> that template is thought for a different structure of spritelayouts 20:21:01 <Terkhen> before, we had one, two or three different ground sprites 20:21:08 <Terkhen> normal, desert, snow 20:21:12 <Terkhen> and different building sprites 20:21:34 <Terkhen> now we want to have a truly tile aware ground sprite 20:21:50 <Terkhen> that takes into account half-desert, partial snow and so on 20:22:03 <Terkhen> that template is already made, and it stores the correct sprite number inside a temporary register 20:22:11 <Terkhen> besides that, we have ground overlays 20:22:30 <Terkhen> the number of ground overlays is not fixed so we can't add that to the template itself 20:24:10 <andythenorth> why don't we fix it? 20:24:24 <andythenorth> there should be 1 ground overlay per tile 20:24:31 <andythenorth> there may be n building sprites 20:26:12 <Terkhen> http://paste.openttdcoop.org/show/559/ 20:26:17 <Terkhen> I'm planning something like that 20:26:30 <Terkhen> you can also have as many buildings as you want 20:27:15 <Terkhen> a example of condition might be terrain_type == TILETYPE_SNOW 20:27:46 <Terkhen> why only a ground overlay? planetmaker mentioned more 20:27:50 <Terkhen> one per tile type IIRC 20:28:04 <andythenorth> hmm 20:28:09 <andythenorth> maybe I misunderstand 20:28:17 <Terkhen> there are many ways of doing this :) 20:28:30 <Terkhen> in my example, all overlays are defined, but they are hidden conditionally 20:28:39 <Terkhen> but we could have a single overlay in the template 20:28:47 <Terkhen> and use another temporary register to store the sprite used for overlay 20:28:56 <Terkhen> and if sprite == 0 -> no overlay 20:29:23 <andythenorth> do we have a case for >1 ground overlay? 20:29:31 <Terkhen> I don't know :P 20:29:57 <Terkhen> IIRC you planned to use them for the black silhouettes of buildings in transparent mode, right? 20:30:09 * Terkhen is usually lost when actual sprites appear in the conversation 20:30:58 <andythenorth> yes 20:31:06 <andythenorth> I am lost with the macros :P 20:31:28 *** JVassie has joined #openttdcoop.devzone 20:31:29 <Terkhen> which ones? 20:32:14 <andythenorth> the spritesets and spritelayouts 20:32:39 <Terkhen> name? 20:32:54 <andythenorth> e.g. tmpl_building_sprite_filename 20:33:17 <Terkhen> ah, yes, those are nml templates 20:33:17 <andythenorth> probably I should just trust them 20:33:52 <andythenorth> I'm currently lost at sea though :) 20:34:01 <Terkhen> usually spritesets use this syntax: [12, 12, 64, 31, -31, 0] 20:34:17 <Terkhen> explained here: http://newgrf-specs.tt-wiki.net/wiki/NML:Realsprites 20:34:25 <andythenorth> yes 20:34:34 <andythenorth> xpos, ypos, crop, offset 20:34:47 <Terkhen> but nml allows you to define templates to write common stuff 20:35:00 <Terkhen> for example, all ground tiles use [x, y, 64, 31, -31, 0] 20:35:17 <andythenorth> k 20:37:22 <Terkhen> common smoke animations are templated as buildings at smoke_templates.pnml 20:39:14 <andythenorth> I saw those :) 20:40:08 <Terkhen> it could be possible to add a animation_offset param so that all smoke in the same industry don't appear at the same time 20:40:19 <Terkhen> s/same time/same frame/ 20:40:32 <andythenorth> do they randomly offset when constructed? 20:40:52 <Terkhen> no 20:40:55 <Terkhen> check the biorefinery for example 20:41:43 <Terkhen> I added the second smoke to it but both smoke fumes move at the same time :P 20:41:48 <andythenorth> nah they're fine as far as I can see 20:41:56 <andythenorth> the brickworks has smoke which is not in sync 20:41:59 <andythenorth> which is correct 20:42:25 <andythenorth> it's fine for two adjacent chimneys to be in sync 20:42:47 <Terkhen> oh, in the brickworks it is done without templates :P 20:42:55 <Terkhen> sprite: 3701 + ((animation_frame + 6) % 8); <--- magic 20:43:10 <Terkhen> I probably made the templates after that 20:43:13 <andythenorth> heh 20:43:16 <andythenorth> I see 20:43:41 <Terkhen> similar "magic" is done for industries with two different animations 20:44:05 <Terkhen> for example the cement plant 20:45:14 <Terkhen> the oil wells animation is a translation to advanced spritelayouts from pm's code in ogfx-industries 20:45:20 <Terkhen> I don't claim to understand that one :P 20:50:13 <planetmaker> hm... I thought you did that one :-P 20:50:46 <Terkhen> I did a simple animation, which was stopped sometimes 20:50:54 <Terkhen> you did the code that stops the animation gracefully 20:51:07 <Terkhen> so neither of us understands that code? :) 20:51:18 <planetmaker> should I look? :-) 20:51:39 <Terkhen> I commented when I was doing the conversion 20:51:44 <Terkhen> it seems that I understood it for a brief period of time 20:51:54 <Terkhen> then again, the comments might be completely wrong :P 20:52:11 <Terkhen> s/commented/added comments/ 20:53:09 <planetmaker> ok, oil well animiation: random bits are re-randomized on the tile loop (256 ticks or so) 20:54:31 <planetmaker> it basically has two loops: frames 0...9 and frames 10...20 20:55:49 <planetmaker> frames 0...9 are for the real animation and 10... 20 the same but animation stops after that cycle is done 20:55:54 <planetmaker> (10 is stop) 20:57:11 <Terkhen> the comments look right then 20:58:10 <planetmaker> on frame 0 we decide whether we switch loops (i.e. continue pumping or decide whether this is the last of the cycle 20:59:03 * andythenorth -> bedtime :) 20:59:40 <planetmaker> that was all the next animation frame. And animation control callback swaps at any time between those loops 20:59:45 <Terkhen> good night andythenorth 20:59:50 <planetmaker> i.e. when pumping go to frame + 10 20:59:54 <planetmaker> good night andy 21:00:20 <planetmaker> or when stopped consider randomly to start pumping. Just finsish, if we're in the "finish animation loop" 21:01:03 <Terkhen> ok :) 21:01:54 *** andythenorth has left #openttdcoop.devzone 21:34:20 *** Hanf has quit IRC 21:58:39 *** frosch123 has quit IRC 22:10:01 *** Zuu has quit IRC 22:19:28 *** ODM has quit IRC 22:22:37 *** JVassie has quit IRC 22:27:47 *** ChanServ changes topic to "Talk about things hosted and developed on http://dev.openttdcoop.org | Downloads log: http://bundles.openttdcoop.org/log.csv | Sandbox passwords are the same as the usernames" 23:22:17 <Brot6> OpenGFX - Revision 733:906be4e859db: Feature: Separate water for rivers (Graphics by Lepkka) (planetmaker) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/906be4e859db