Times are UTC Toggle Colours
00:08:04 <Brot6> ::DevZone:: OpenSFX - Feature #397: Sample 40: Sawmill @ https://dev.openttdcoop.org/issues/397#change-1121 (by Roujin) 00:14:56 <Brot6> ::DevZone:: OpenSFX - Feature #397: Sample 40: Sawmill @ https://dev.openttdcoop.org/issues/397#change-1122 (by Rubidium) 00:30:18 <Frankr> Cya 00:30:20 *** Frankr has quit IRC 01:12:11 <Brot6> ::DevZone:: Redmine - Revision 2689: (svn r2840) Added branch and tag support to the git repository viewer. (... @ https://dev.openttdcoop.org/projects/redmine/repository/revisions/2689 (by edavis10) 01:33:37 <Brot6> Backup done! (Usage: 93M) 01:33:37 <Brot6> You were s'posed to laugh! 06:14:33 *** andythenorth has joined #openttdcoop.devzone 06:14:37 *** openttdcoop sets mode: +v andythenorth 06:22:45 *** andythenorth has quit IRC 06:44:06 <Brot6> ::DevZone:: OpenGFX - Feature #438: source release @ https://dev.openttdcoop.org/issues/438 (by planetmaker) 06:48:26 <Rubidium> that sounds familiar ;) 07:07:21 <planetmaker> hehe :-) Good morning Rubidium :-) 07:09:26 <Rubidium> what's the point of defining CAT_MODIFIED after using it in Makefile.config? (at least in osfx) 07:09:40 <planetmaker> And "why so many dev channels": .dev is the server channel for playing, this is the devzone :-) 07:10:18 <planetmaker> it should be either "" or "M" 07:10:28 <planetmaker> depending whether it's a modified source directory or not 07:10:50 <Rubidium> planetmaker: I was more thinking about 07:11:00 <Rubidium> FOO = bla$(BAR) 07:11:04 <Rubidium> lines later 07:11:13 <Rubidium> BAR = as 07:12:28 <planetmaker> VERSION_STRING = $(shell [ -n "$(REPO_TAGS)" ] && echo $(REPO_TAGS)$(CAT_MODIFIED) || echo $(CAT_NIGHTLYNAME)-r$(CAT_REVISION)$(CAT_MODIFIED)) <-- that line? 07:12:38 <Rubidium> planetmaker: yup 07:12:50 <Rubidium> it amazes me that it works 07:13:14 <planetmaker> well. That actually stitches together the whole version string: nightly r145 M 07:13:28 <Rubidium> planetmaker: yes, I know THAT 07:13:34 <planetmaker> :-) 07:13:52 <planetmaker> well. If the current version is tagged, I assume it's a release version. 07:14:12 <Rubidium> what I am amazed about is that using a variable BEFORE it gets declared (magically) makes it valid and 'useful' BEFORE it's declaration 07:14:13 <planetmaker> so I use the tag as version 07:14:29 <planetmaker> you mean CAT_MODIFIED? 07:14:35 <planetmaker> it should be declared there 07:14:42 <Rubidium> yes 07:15:22 <planetmaker> as it's declared in Makefile, not Makefile.config 07:15:40 <Rubidium> planetmaker: it is declared AFTER the include of Makefile.config 07:15:48 <planetmaker> nope :-) 07:16:02 <planetmaker> well, Makefile.config is there twice :-P 07:16:33 <Rubidium> rubidium@strontium:~/openttd/special/opensfx$ grep -n MAKEFILECONFIG Makefile 07:16:37 <Rubidium> 4:MAKEFILECONFIG=Makefile.config 07:16:39 <Rubidium> 26:include ${MAKEFILECONFIG} 07:16:40 <Rubidium> my grep doesn't agree 07:16:43 <Rubidium> rubidium@strontium:~/openttd/special/opensfx$ grep -n CAT_MODIFIED Makefile* 07:16:44 <planetmaker> 37 07:16:46 <Rubidium> Makefile:33:CAT_MODIFIED = $(shell [ -n "`hg status \"." | grep -v '^?'`" ] && echo "M" || echo "") 07:16:49 <Rubidium> Makefile.config:57:VERSION_STRING = $(shell [ -n "$(REPO_TAGS)" ] && echo $(REPO_TAGS)$(CAT_MODIFIED) || echo $(CAT_NIGHTLYNAME)-r$(CAT_REVISION)$(CAT_MODIFIED)) 07:16:55 <planetmaker> oh, no. sorry 07:18:10 <planetmaker> hm... I have to look :-) 07:19:05 <planetmaker> it should in my understanding be declared prior to usage :-) 07:20:52 <planetmaker> but it really works :-O 07:25:25 <planetmaker> same actually with REPO_TAGS 07:28:19 <Rubidium> so 'only' creating a Makefile.local with the appropriate settings does the trick 07:28:54 <Rubidium> and that doesn't create the warnings of a missing hg 07:31:03 <EdorFaus> The CAT_REVISION thing is not an error actually - I found that similar stuff works while playing with a makefile for my own code, and it's documented too. 07:31:56 <Rubidium> EdorFaus: wrong or not, it goes against any 'sane' programming principles 07:31:57 <EdorFaus> setting variables with = doesn't expand variables used in that setting. so changing the used variables later will be reflected in the new variable when that is used 07:32:18 <Rubidium> nevertheless, because it works: it's easy to implement #438 07:32:49 <EdorFaus> however, setting a variable with := expands it right then and there, meaning changes in the used variables will not be reflected in the new one. 07:34:40 <EdorFaus> basically, FOO= foo $(BAR) baz references BAR not by value, but by reference. 07:37:26 <EdorFaus> (and I can't really see references as being insane... though I do realize it might seem a bit odd to have several references assigned to a single variable) 07:40:35 *** ODM has joined #openttdcoop.devzone 07:40:50 *** openttdcoop sets mode: +v ODM 07:46:41 <Rubidium> http://rbijker.net/openttd/osfx-release-tgz.diff <- seems to work 07:46:56 <Rubidium> requires a clean checkout though 07:55:30 <EdorFaus> hm. I should commit my latest code to the hg repo (C++ code that replaces the PHP sprite "compiler" for the box editor - much faster, fewer dependencies, etc...) but I'm not sure how best to do that. See, it depends on the code for grfcodec. So should I have the makefile check it out from svn and compile it, or add that to the repo as well (sortof forking it), or just add a note about it somewhere, or..? 07:57:04 <Rubidium> it's a tool that isn't needed for compiling OpenGFX, right? 07:57:44 <Rubidium> (just useful for generating a few sprites which then get added to the HG repo) 07:57:50 <EdorFaus> indeed. it's only needed to get all the features out of the box editor - which isn't needed either, it's just that it's a custom tool used to make some of the sprite graphics. 07:58:08 <EdorFaus> right. 07:59:54 <EdorFaus> there was talk about making an automated version of the tool that would automatically generate the sprites when OpenGFX was compiled, but it doesn't work like that right now, and might never do (I'm not so sure it's a good idea tbh) 08:00:10 <Rubidium> then I think you can do the 'checkout specific revision of grfcodec' trick (but that's my personal experience) 08:00:25 <EdorFaus> ok. 08:00:39 <Rubidium> s/experience/opinion/ 08:01:05 <Rubidium> since you don't use svn you can't use svn:externals 08:01:39 <EdorFaus> *nod* 08:02:04 <Rubidium> although svn:externals can be troublesome in some situations 08:03:10 <planetmaker> Rubidium: but svn:externals... would it work with a hg repo? :-) 08:03:53 <Rubidium> planetmaker: what do you think when I say you can't use svn:externals because you don't use svn? 08:04:31 <Rubidium> also, check the openttd trunk.hg at the time noai got trunked 08:04:34 <planetmaker> oh. Missed totally that line. 08:05:18 <ODM> mornin 08:05:27 <planetmaker> moin ODM 08:07:52 <planetmaker> and indeed, Rubidium using the definitions of REPO_TAGS, CAT_REVISION and CAT_MODIFIED in Makefile.local might do the trick for the source release (I haven't yet looked at your .tar.gz) 08:08:19 <planetmaker> Do you modify the makefile of ogsx or shall I do it in order to keep it in sync with ogfx? 08:09:07 <Rubidium> ogsx -> osfx ? 08:09:29 <planetmaker> yes 08:09:33 <Rubidium> if so, please commit your variant of whatever goes into ogfx ;) 08:09:39 <planetmaker> ok :-) 08:12:42 <Brot6> ::DevZone:: OpenGFX - Revision 191: Change [Makefile]: Declare variables before usage (though declaration via... @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/191 (by planetmaker) 08:14:26 <ODM> whats osfx?:P 08:14:30 <Brot6> ::DevZone:: OpenSFX - Revision 39: Change [Makefile]: Declare variables before usage (though declaration via ... @ https://dev.openttdcoop.org/projects/opensfx/repository/revisions/39 (by planetmaker) 08:16:12 <planetmaker> ^^ 08:17:06 <ODM> sneaky 08:17:31 <Rubidium> yay! sense (not so much the simplicity) 08:27:06 *** andythenorth has joined #openttdcoop.devzone 08:27:11 *** openttdcoop sets mode: +v andythenorth 08:43:33 *** LordAzamath has joined #openttdcoop.devzone 08:43:40 *** openttdcoop sets mode: +v LordAzamath 09:04:10 <Brot6> ::DevZone:: OpenGFX - Revision 192: Feature [Makefile]: target 'release_source' allows to distribute source f... @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/192 (by planetmaker) 09:10:08 <Brot6> ::DevZone:: OpenSFX - Revision 40: Feature [Makefile]: target 'release_source' allows to distribute source fo... @ https://dev.openttdcoop.org/projects/opensfx/repository/revisions/40 (by planetmaker) 09:11:10 <Rubidium> woohooo :) 09:13:22 <LordAzamath> lol you're not the only one committing there anymore :D 09:13:42 <Rubidium> LordAzamath: I haven't been the only one since like... r0 09:13:49 <planetmaker> :-D 09:14:09 <planetmaker> my contributions are... minor :-) 09:14:27 <Rubidium> no, Ammler's contributions are minor ;) 09:14:27 <LordAzamath> and Rubidium makes adult commits 09:14:32 <LordAzamath> :D 09:14:33 <planetmaker> :-P 09:14:41 <Rubidium> and the statistics are screwed 09:14:47 <planetmaker> hm? 09:15:02 <Rubidium> https://dev.openttdcoop.org/projects/opensfx/repository/statistics <- I'm fairly sure I'm sober 09:15:08 <Rubidium> but I'm seeing things double 09:15:26 <planetmaker> right. Me too :-) 09:15:45 <planetmaker> Might be different computers I work from... 09:16:20 <LordAzamath> seems the lower pc is more productive 09:16:22 <LordAzamath> :D 09:17:50 <planetmaker> Let's port the stuff to the generic makefile, too :-) 09:19:24 <Brot6> ::DevZone:: Generic NewGRF Makefile - Revision 23: Feature [Makefile]: target 'release_source' allows to dist... @ https://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/23 (by planetmaker) 09:25:55 <planetmaker> Rubidium: an idea for bananas: add the possbility to distribute the source, too :-) Makes sense for GPL-license grfs at least :-) 10:04:06 <Brot6> opengfx: Backup push to ssh://hg@bitbucket.org/OpenTTD/opengfx/ initiated. 10:04:11 <Brot6> opensfx: Backup push to ssh://hg@bitbucket.org/OpenTTD/opensfx/ initiated. 10:11:15 <Ammler> good day guys 10:11:43 <Ammler> planetmaker: / Rubidium will you add a target for the src.tar.gz thing? 10:13:44 <Ammler> what about adding a file called VERSION to the tar.gz, so it would work without hg? 10:18:24 <Ammler> oh, and planetmaker does use 2 different names, on one pc he is pm <email> on the other without email, that is why he is double. 10:18:26 <Rubidium> Ammler: there already is a 'make release_source' that makes the source .tar.gz which works without HG 10:21:58 <Ammler> wow, does it use the version from the directory then? 10:22:15 <Ammler> well, I should just test it :-) 10:22:27 <Rubidium> or read the diff ;) 10:23:33 <Ammler> oh, and sorry about the confusion with the other dev channel. We used the other one for patch server for a long time already. So we needed a new channel for the devzone. 10:27:15 <Rubidium> planetmaker: there's currently no way that you would be able to download those sources 10:27:24 <Ammler> Rubidium: where do you make the "border" between clean and mrproper? 10:28:12 <Rubidium> so it doesn't make much sense now, maybe later, but make a feature request at the website bug tracker so TB doesn't forget it 10:28:35 <Rubidium> Ammler: good question ;) 10:28:59 <Ammler> we "packed" everything into clean yet 10:29:05 <Rubidium> clean is usually just remove the stuff so it recompiles, whereas mrproper removes everything that isn't in the repository 10:34:06 <planetmaker> [12:26] <Rubidium> planetmaker: there's currently no way that you would be able to download those sources <-- I know that :-). So it's probably a feature request either way: bundled with the grf (probably unnecessary) or as separate download (better IMO) 10:34:21 <planetmaker> I'll make a feature request for it on FS 10:34:45 <planetmaker> [12:18] <Ammler> oh, and planetmaker does use 2 different names, on one pc he is pm <email> on the other without email, that is why he is double. <-- let's see. It should be feasable to change that :-) 10:35:01 <Ammler> :-) 10:35:36 <Ammler> btw. how does the readme look on a native windows? 10:36:03 <planetmaker> No idea yet. Haven't tested 10:36:08 <Ammler> (can't handle \n) 10:42:12 <Ammler> I am a bit unsure about the source distribution, 10:42:31 <Ammler> as the grf is the same all plattforms 10:43:10 <Ammler> so you could as good use the usual release pack as source for package maintainers. 10:44:35 <planetmaker> The point was: currently you cannot make the release grf without the VCS install. release_source changes that by creating a modified Makefile.local and packing the whole thing in a separate tar.gz 10:45:11 <planetmaker> basically it's in analogy to the source releases of OpenTTD and alike. So you can download the source and be happy without repository access. 10:45:21 <Ammler> yeah, I see, I just wondering why "someone" should need 10:45:41 <planetmaker> Ammler: for packat distributions like Gentoo, SuSE, etc pp 10:45:48 <planetmaker> *packet 10:45:55 <Ammler> [12:43] <Ammler> so you could as good use the usual release pack as source for package maintainers. 10:46:21 <planetmaker> For them. But those distributions want / have to ship the source of what they ship 10:46:33 *** LordAzamath has quit IRC 10:46:35 <Ammler> for openttd, you need to create the binaries fresh, as you have other libs on different distros 10:46:36 <planetmaker> And for that purpose a source package is better 10:46:59 <planetmaker> it's not about creating it for the distro. It's about distributing the source 10:47:06 <Ammler> nono 10:47:10 <planetmaker> The source of that exact newgrf 10:47:17 <Ammler> they also use the source for creating it. 10:47:22 <planetmaker> ... 10:47:27 <Ammler> ie. rpms are done like that. 10:47:36 <Rubidium> Ammler: distributions want to be able to compile binaries themselves 10:47:47 <planetmaker> Ammler: there's a difference between creating the binary for a distro and creating the source release for a distro 10:49:13 <Rubidium> http://cvs.fedoraproject.org/viewvc/rpms/openttd-opengfx/F-11/openttd-opengfx.spec?revision=1.1&view=markup 10:50:38 *** bushwacker has joined #openttdcoop.devzone 10:50:39 *** bushwacker has left #openttdcoop.devzone 10:51:16 <Brot6> ::DevZone:: World Airliners Set - Feature #439: Sort A330-300 Greyscale @ https://dev.openttdcoop.org/issues/439 (by Beardie27) 10:52:39 <Rubidium> also, for consistency you might want to remove the windows newlines from license.txt 10:53:23 <planetmaker> the question is whether we want to add them everywhere in the *.txt... 10:53:59 <Rubidium> please don't :) 10:54:22 <planetmaker> Rubidium: but if windows users cannot read it properly? 10:54:28 <Rubidium> you might want to consider unix2dos-ing them if you make a (release) .zip 11:00:44 <Rubidium> because in the .tar.bz2 you've got the tar that you bzip2, in the .zip you've got the tar *and* 3 text files (which you can unix2dos, because they don't get added to the .tar.bz2) 11:02:40 <Rubidium> actually zip -l ;) 11:02:43 <Ammler> those windows users who can't read it proper, don't read it anyway. Else they would have updated the editor long time ago ;-) 11:04:29 <Rubidium> http://rbijker.net/openttd/this_and_dos2unix_license_txt_and_zip_has_crlf_and_tar_has_lf.diff 11:06:21 <Ammler> mäh, do I need to install zip on the server? 11:06:45 <Rubidium> if your 'zip provider' does support that feature, no 11:07:44 <Ammler> hmm, 7z is the zip creator... 11:08:51 <Rubidium> then you might have to opt for a slightly more complex routine 11:09:20 <Rubidium> which involves some copying before unix2dos-ing 11:10:46 <Ammler> well, installing zip might be easier 11:19:21 <planetmaker> hm... interesting command line option to zip :-) 11:20:48 *** LordAzamath has joined #openttdcoop.devzone 11:20:55 *** openttdcoop sets mode: +v LordAzamath 11:22:44 <Ammler> then we distribute 2 different packs from now on? (tar.gz or bz2 and zip) 11:22:46 <planetmaker> so... going for "zip -l", Ammler ? 11:23:08 <planetmaker> zip for win and bz2 for lin? :-) 11:23:20 <Ammler> that the question 11:23:33 <planetmaker> hm... I'm not too hapy with two different packs. 11:23:40 <Ammler> as with the "new" zip we break the readme for those users who actually read it. 11:23:56 <planetmaker> CFLF isn't really broken for lin / mac users 11:24:00 <Rubidium> Ammler: break the readme? 11:24:18 <Ammler> well, just a ugly ^M at the end 11:24:33 <FooBar_> Ammler: get a proper editor ;) 11:24:58 <planetmaker> indeed :-P 11:25:03 <Rubidium> Ammler: then *if* the newline is a problem for the ones that read it, make everything unix-newline and don't care about converting! 11:25:10 <Ammler> FooBar_: the readme is for the newbie 11:25:26 <planetmaker> Ammler: vim doesn't show ^M for me 11:25:39 <planetmaker> nor does less 11:25:42 <Rubidium> hexedit does! 11:25:48 <Rubidium> well, not ^M 11:25:49 <planetmaker> :-D 11:25:55 <Rubidium> but it shows the \r 11:25:59 <Ammler> hmm 11:26:06 <Rubidium> (old) joes did too 11:26:11 <planetmaker> sounds like the editor of choice for text files :-P 11:26:20 <planetmaker> (hexedit) 11:26:22 <Ammler> then what is the issue, if we make just a zip with CFLF? 11:26:23 <FooBar_> tbh, I don't care what the line endings are; I /have/ a proper editor 11:26:37 <Ammler> FooBar_: NEWBIE! 11:26:50 <Rubidium> Ammler: nothing, as long as you leave the sources LF (without CR) 11:27:11 <Ammler> ok then I install zip on the server and we add -l 11:28:21 <planetmaker> well. Then we should rather convert license.ptxt and then we don't need -l anyway 11:28:35 <planetmaker> well... if want special dos line endings we do 11:28:54 <Ammler> hmm, and I wouldn't need to install zip :-) 11:28:59 <planetmaker> can we assume that win users always use *zip, not *bz2 or *tar? 11:29:07 <Ammler> yes 11:29:15 <Ammler> well, tar 11:29:15 <planetmaker> then it would kinda make sense 11:29:21 <FooBar_> yes, especially since Windows can open zip natively 11:29:30 <planetmaker> right 11:29:59 <FooBar_> and everything else it can't 11:30:46 <planetmaker> ok, for consistency, I'll commit the changed license with LF only 11:31:38 <planetmaker> hm... should I do that with authoroverview.csv, too? 11:31:53 <FooBar_> No, I'll break that the next update :P 11:32:20 <planetmaker> :-P 11:32:25 <planetmaker> Get a proper editor :-P 11:32:27 <Ammler> well, theoretically, every text file should be converted to LF only by the VCS 11:32:44 <FooBar_> Then we need a proper VCS :P 11:32:51 <FooBar_> as it clearly doesn't do that... 11:32:54 <Rubidium> FooBar_: lucky for you there won't be an update of the license file ;) 11:32:56 <Ammler> with the csv 11:33:06 <planetmaker> Rubidium: hm? 11:33:28 <FooBar_> Rubidium: heh, yes indeed. But I wouldn't break that as I don't use Excel to open that :P 11:33:36 <Rubidium> oh, he's talking about a csv ;) 11:33:57 <Ammler> hmm 11:34:03 <planetmaker> FooBar_: I always edit as a text file :-) 11:34:42 <FooBar_> good for you ;) 11:35:03 <planetmaker> hm... so we leave that inconsistency? 11:35:12 <planetmaker> sounds... strange then 11:35:13 * Rubidium has his own 'special' file format for the author list ;) 11:35:18 <FooBar_> I'm not happy with inconsistencies tbh... 11:35:34 <FooBar_> Rubidium: what's that then? 11:35:35 <Ammler> reanem the authoroverview to txt? 11:35:39 <planetmaker> Rubidium: you mean for opensfx? 11:35:48 <Rubidium> planetmaker: yeah, opensfx ;) 11:35:50 <FooBar_> Ammler: that breaks my website :P 11:36:00 * FooBar_ checks opensfx 11:36:01 <planetmaker> Ammler: then it would need a better csv formating e.g. spaced by tabs or so 11:36:16 <planetmaker> FooBar_: that could be fixed (the website) 11:37:09 <FooBar_> possibly, but I don't see why we should use the .txt extension for a file with csv contents 11:38:03 <FooBar_> tabs are annoying, as you'd have to re-tab the whole file if some intermediate "cell" gets a bigger content 11:38:03 <Ammler> well, I am not sure at all, if mercurial does convert txt files, does it FooBar_? 11:38:24 <planetmaker> yeah, tab is not good. I just see that :-) 11:38:40 <FooBar_> Ammler: I think it doesn't, as the license file wasn't converted 11:39:14 <Ammler> so is that a svn only feature? 11:39:54 <Rubidium> IIRC you can teach hg to change newlines *but*... only on a whole repository basis, which means it might occasionally trash binary files (like .png) 11:40:01 <FooBar_> http://trentm.com/blog/archives/2007/09/13/mercurial-needs-better-end-of-line-support/ 11:40:03 <Webster> Title: trentm.com blog archive mercurial needs better end-of-line support (at trentm.com) 11:40:23 <Rubidium> although .png has a nice mechanism to find that ;) 11:40:37 <Ammler> might be disadvantage of Dvcs 11:42:19 <Rubidium> http://mercurial.selenic.com/wiki/Win32TextExtension 11:42:21 <Webster> Title: Win32TextExtension - Mercurial (at mercurial.selenic.com) 11:46:49 <Rubidium> http://bundles.openttdcoop.org/opensfx/releases/ <- I wonder when people stop believing last modified dates ;) 11:46:55 <FooBar_> That's an interesting extension 11:47:43 <FooBar_> the hook is interesting as well IMO 11:48:55 <planetmaker> Rubidium: what's wrong with "last modified"? 11:49:07 <FooBar_> Maybe it's modified today ;) 11:49:15 <planetmaker> wasn't the 0.1.0-alpha2 from day before yesterday? 11:49:25 <Rubidium> planetmaker: yes 11:49:37 <Rubidium> but from when do you think the source package is? 11:49:47 <planetmaker> :-D 11:49:58 <planetmaker> long may live "touch" ;-) 11:51:07 <planetmaker> FooBar_: will you be able to handle unix style LF in the csv? 11:51:16 <planetmaker> then I'd change that, too 11:51:26 <FooBar_> If that extension does what it says it does: yes :) 11:51:37 <planetmaker> so, you'll give it a try? 11:51:52 <FooBar_> yes 11:51:54 <planetmaker> (or does it need to be installed on the server? I'm not sure yet) 11:52:00 <FooBar_> no, on my side 11:52:09 <planetmaker> good. I'll check the (p)nfo files, too 11:52:19 <FooBar_> The hook can be installed on the server, but that isn't mandatory for it to work 11:52:40 <FooBar_> the hook is useful to enforce LF though 11:52:54 <Rubidium> http://paste.openttd.org/199127 <- seems to be a 'mess' w.r.t. encoding etc ;) 11:52:54 <FooBar_> I'd recommend it as well 11:53:39 <FooBar_> the line terminators seem consistent ;) 11:54:42 <planetmaker> I wonder whether renum / grfcodec like just LF 11:55:17 <Rubidium> planetmaker: they do like just LF 11:55:27 <planetmaker> :-) 11:55:29 <Rubidium> at least the unix ones 11:56:08 <FooBar_> oh Rubidium by the way, sorry for the triple reopen request for FS#3000 yesterday. I hit F5 to reload the page to view changes, but that silently resubmitted the request without the usual warning. 11:56:53 <planetmaker> Rubidium: how did you get these file information you just pasted? 11:57:17 <Rubidium> 'file *' in the apropriate directory 11:57:40 <planetmaker> cool & thx. I didn't know that command at all :-) 11:58:50 <Rubidium> it's just one of the many many many small, but very useful, tools ;) 11:59:04 <Rubidium> although occasionally it isn't right 11:59:06 <Rubidium> e.g. 11:59:14 <Rubidium> readme.txt: Lisp/Scheme program text 11:59:17 <Rubidium> for OpenSFX 12:00:17 <Brot6> ::DevZone:: World Airliners Set - Revision 413: Updated #418 - Added IL62 Co-ordinates, not calculated minus ... @ https://dev.openttdcoop.org/projects/worldairlineset/repository/revisions/413 (by Beardie27) 12:02:09 *** andythenorth has quit IRC 12:02:54 <planetmaker> I wonder whether the file type for all pnfo files should be exactly the same... it's quite different now with some files non-ISO extended-ASCII C++ program 12:03:58 <Rubidium> planetmaker: having it all in the same encoding (UTF8 preferably), makes it easier to teach your text editor to open it with the right encoding so it doesn't corrupt the file 12:04:04 <FooBar_> We dicussed what to do if something ain't broke yesterday I believe :P 12:04:16 <planetmaker> :-P 12:04:27 <planetmaker> Well, but beautification is something else :-) 12:05:17 <Ammler> I guess, that are the files with the pseudo recolor sprites 12:05:29 <Ammler> those can't be utf-8 12:05:57 <Rubidium> Ammler: recolour sprites can be perfectly ASCII 12:06:58 <planetmaker> hm... my editor sais utf-8 for the pnfo files while file does tell ASCII C++ program text, with CRLF line terminators 12:07:08 <Ammler> hmm, last time I forgot to convert encoding to iso-8859-1, I broke the grf 12:07:20 <Rubidium> http://paste.openttd.org/199128 12:07:58 <Rubidium> planetmaker: ASCII == utf-8 as long as no non-ASCII characters are used 12:08:41 <planetmaker> ah. 12:08:51 <planetmaker> yes, for those non-iso files it is different 12:08:55 <Rubidium> but it looks like you decompiled ottd_grf instead of taking the source of ottd_grf as base 12:09:30 <planetmaker> I guess that was done. Complain to FooBar_ :-P 12:09:48 <Ammler> yes, foobar didn't know about your source :-) 12:10:03 <Ammler> but that is loooong ago 12:10:31 <planetmaker> in an age long past ;-) 12:10:32 <Rubidium> :O, then I'll cook up a patch to 'fix' ogfxt_toyland.pnfo 12:11:00 <planetmaker> shrouded by the clouds of history and faulty memories :-) 12:11:22 <Ammler> well, if you ask me, you could easy commit it self :-) 12:11:31 <Ammler> but I am not manger there ;-) 12:11:57 <planetmaker> where? OpenGFX? 12:12:00 <Ammler> yes 12:12:22 <planetmaker> contributor is sufficient :-P 12:12:41 <planetmaker> or developer 12:12:53 <Ammler> you need to be developer to commit. 12:13:14 <planetmaker> and you are. For ages 12:13:21 <Ammler> well, you know theoretically 12:13:30 <Ammler> yes, I am, but rubi isn't 12:14:00 <planetmaker> let's update the base a bit :-) 12:14:04 <planetmaker> and promote two people 12:14:43 <planetmaker> I hope the other manager won't mind ;-) gell, FooBar_ ? 12:21:58 <Rubidium> http://rbijker.net/openttd/ogfxe_use_less_non-ASCII.diff 12:22:45 <Rubidium> I hope you don't mind replacing the 13 * 257 with -1 * 0 ;) 12:23:29 <Brot6> ::DevZone:: OpenGFX - Revision 193: Change: Convert all text files to utf-8 and unix-style line endings @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/193 (by planetmaker) 12:24:48 <planetmaker> Hm... what is then the advantage to replace the utf-8 by ascii? 12:25:01 <planetmaker> IMO it makes the whole thing WAY less readable. 12:25:15 <Rubidium> planetmaker: you've read my diff? 12:25:22 <planetmaker> I'm looking at it, yes 12:25:42 <Rubidium> what you've just done by converting the file to utf-8 is horribly break the 2CC colour mapping 12:26:17 <Rubidium> check the warnings 12:27:32 <planetmaker> :S 12:28:45 <Rubidium> http://rbijker.net/openttd/ogfxe_use_less_non-ASCII.diff <- against the updated repository (fixes all warnings) 12:29:23 <Rubidium> also md5sum with this applied is the same as with r192 (so no functional changes) 12:30:29 <Ammler> :-) pm is known to test after commit ;-) 12:30:38 <planetmaker> pffft! 12:32:46 <Ammler> planetmaker: I am on the server shall I run hg rollback? 12:33:26 <planetmaker> I hate to do that on the server. Especially as it has been pulled 12:33:54 <Rubidium> just commit the fix ;) 12:35:36 <planetmaker> hm... I find the Non-ISO extended-ASCII C++ program text way better readable (as it shows the actual characters) than the hex codes 12:35:52 *** andythenorth has joined #openttdcoop.devzone 12:35:57 *** openttdcoop sets mode: +v andythenorth 12:36:10 <Rubidium> planetmaker: huh? 12:36:12 <Ammler> the charakters for the 2cc translations don't care 12:36:24 <Ammler> there it is imo better to have numbers 12:36:48 <Rubidium> you mean "≤≥¥µ∂∑∏π∫ªºΩæø¿¡¬√ƒ≈∆«»… ÀÃÕŒœ–—“”‘’÷◊ÿŸ⁄€‹›fifl‡·‚„" is more clear to you than "1 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98" when talking about indices in the (base) palette? 12:37:08 <planetmaker> hm... I guess I meant that :-P 12:37:17 <Ammler> :-) 12:37:29 <planetmaker> ok, let's fix that :-) 12:37:34 <Rubidium> also = "ˇˇˇˇ" is more clear than = FF FF FF FF 12:40:57 <Ammler> after that fix, I don't need to switch to iso-8859-1 anymore? 12:41:07 <planetmaker> I'd say: yes 12:41:09 <Rubidium> Ammler: that's the idea 12:41:30 <Brot6> ::DevZone:: OpenGFX - Revision 194: Fix (r193): use less non-ASCII characters and write the colour palettes a... @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/194 (by planetmaker) 12:41:36 <planetmaker> aeolusreloaded:~/ottd/grfdev/opengfx ingo$ file sprites/*.pnfo 12:41:37 <planetmaker> sprites/ogfx1_base.pnfo: UTF-8 Unicode C++ program text 12:41:39 <planetmaker> sprites/ogfxc_arctic.pnfo: ASCII C++ program text 12:41:40 <planetmaker> sprites/ogfxe_extra.pnfo: ASCII C++ program text 12:41:42 <planetmaker> sprites/ogfxh_tropical.pnfo: ASCII C++ program text 12:41:43 <planetmaker> sprites/ogfxi_logos.pnfo: ASCII C++ program text 12:41:45 <planetmaker> sprites/ogfxt_toyland.pnfo: ASCII C++ program text 12:42:14 <Ammler> same with base 12:42:30 <FooBar_> planetmaker: no I don't mind :) 12:42:57 <Rubidium> planetmaker: toyland is ISO8859 for me? 12:42:59 <planetmaker> Ammler: what do you mean? 12:43:30 <Ammler> ogfx1_base.grf has same issue as extra 12:44:02 <planetmaker> uhm... I don't have any compile error now with r194. And the shown type is what I just posted here. 12:44:34 <Rubidium> planetmaker: what did you use to convert the encoding? 12:44:50 <planetmaker> xcode 12:45:05 <planetmaker> it has a selection of several different encodings I can chose from 12:45:08 <planetmaker> I chose utf-8 12:45:28 <Rubidium> it did a lousy job 12:45:48 <Rubidium> see extra.pnfo:4192 and further 12:46:39 <planetmaker> he... 12:55:11 <Rubidium> http://rbijker.net/openttd/ogfx_more_fixes.diff <- fixes more recolour sprites 12:55:37 <Ammler> push it :-) 12:57:39 <Rubidium> there's still something 'wrong' in base though 12:58:02 <planetmaker> pro'ly the same stuff as in _extra... 12:58:24 <Rubidium> planetmaker: no, this is 'worse' as the md5sum of the generated grf differs 13:00:46 <Ammler> http://pastebin.ca/1531426 <-- that is what I run to skip the pseudo sprites 13:07:56 <Rubidium> yay, found the culprit ;) 13:08:09 <Ammler> Rubidium: https://dev.openttdcoop.org/my/account <-- maybe you should make mail notifications a bit more silent 13:08:22 <Ammler> as your filter doesn't allow too many mails 13:09:40 <Rubidium> huh? 13:10:40 <Ammler> well, currently it is fine, but yesterday my server wasn't able to send mails through filter.iseer.nl 13:10:59 <Rubidium> slap TB :) 13:11:07 <planetmaker> :-P 13:11:13 <Rubidium> it's not like I want to be notificated of everything ;) 13:11:14 <Ammler> yeah, I already did, maybe that is the reason it works now. :-) 13:11:16 <planetmaker> he kicked back as far as I saw it :-P 13:11:49 <Ammler> I set it to notifications only for things I am involved or watch 13:12:01 <Ammler> and disabled mails for own changes 13:12:09 <Brot6> ::DevZone:: OpenGFX - Revision 195: Fix (r193): write the colour palettes (in base and toyland) as hex array ... @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/195 (by Rubidium) 13:12:41 <Ammler> but default is a bit more verbose 13:14:33 <Ammler> hmm, toyland has also a recolor sprite 13:24:36 <Rubidium> md5s from before and after the conversion (of the produced grfs) are the same again 13:25:31 <Rubidium> only the "characters" section of extra contains broken characters in the comments 13:27:18 <planetmaker> I think I have a fix for the latter now 13:27:41 <planetmaker> not having used the conversion before, I did it wrong [TM] 13:28:13 <Rubidium> with such things it's usually best to do it in stages anyway 13:28:31 <Rubidium> first \r\n -> \n 13:28:41 <planetmaker> yes 13:28:56 <planetmaker> I figured.... now 13:28:58 <Rubidium> because doing that with the conversion made it impossible to see what was actually char converted and what only got a change in newline 13:29:18 <Rubidium> but... it's something you've learned now and can use that experience the next time ;) 13:29:26 <planetmaker> :-) 13:41:57 <Ammler> https://dev.openttdcoop.org/projects/opengfx/repository/revisions/185 <-- shouldn't we make a seperate project for the editor? 13:44:44 <planetmaker> I don't think. It's an editor only used for OpenGFX 13:45:05 <planetmaker> who else wants to wrap his/her sprites into patterned boxes? 13:45:09 <Ammler> now, can't it be more? 13:45:14 *** andythenorth has quit IRC 13:47:44 <Ammler> well, it could be subproject of opengfx 13:48:03 <Ammler> but you don't need the editor to make the grf 14:13:22 <Brot6> ::DevZone:: World Airliners Set - Feature #443: Implement New Ryan Air 737-800 and fixed Thomson 737-800 Sprites @ https://dev.openttdcoop.org/issues/443 (by FaddyPainter) 14:52:53 <planetmaker> Sure, you don't need the editor to make the newgrf. But... it's part of OpenGFX. 15:03:51 <Rubidium> planetmaker: is it needed for building OGFX from scratch? 15:24:38 <planetmaker> Rubidium: it's not. The pcx are there. 15:24:40 <planetmaker> but it will come in handy, if sprites need updating 15:24:42 <planetmaker> e.g. the house graphics change 15:31:44 <Rubidium> tricky ;) 15:32:41 <Rubidium> if, lets call them compile-a-binary noobs, want to use it it would be useful if you've got precompiled binaries of it 15:32:59 <planetmaker> Basically it's a tool to help the graphics artist IMO. Though all wrappings so far were generated using it.... 15:33:23 <planetmaker> hm... but then not in the repo. They could be added to the OpenGFX documents or files section though 15:33:29 <Rubidium> and compiling a binary (regularly) is easiest with it's won repository 15:33:44 <Rubidium> s/wo/ow/ 15:33:46 <planetmaker> ha, I won a repository ;-) 15:34:35 <Rubidium> hmm, also s/'// 15:35:23 <Rubidium> ofcourse with svn repository usually means 'part of repository' 15:42:42 <planetmaker> hg 1.3 has a functionality called subrepositories. But that's still considered experimental... 15:43:07 <planetmaker> and there's a hg extension called forrests... 15:43:32 <Ammler> ah, that is just detail 15:43:57 <Rubidium> I'd keep away from experimental stuff and non-standard extensions as much as possible 15:44:05 * planetmaker would, too 15:44:27 <planetmaker> at least for the vcs I base my work on :-) 15:45:00 <Ammler> I don't see issue to have it in a sep. repo 15:45:18 <Ammler> and managing it as subproject of opengfx 15:46:06 <Ammler> well, it doesn't matter anyway anymore. As it is already in the ogfx repo ;-) 15:46:29 <Ammler> and you don't like me to strip it out. 15:46:38 <planetmaker> :-D 15:47:05 <planetmaker> what's the difference between strip and patch -R ? 15:47:25 <Rubidium> strip - Discard symbols from object files 15:47:35 <Ammler> strip is real remove 15:47:35 <Rubidium> patch -R reverses a given patch 15:47:51 <Rubidium> or are you talking about another strip? 15:47:54 <Ammler> if you just revert the commit, you have it still in the history 15:48:13 <planetmaker> Rubidium: hg strip :-) 15:48:26 <Ammler> strip removed the changeset 15:48:37 <Ammler> s/d/s 15:48:46 <planetmaker> ok, strip is re-writing history :-) 15:49:01 <planetmaker> while patch -R just un-does historic changes 15:49:04 <Ammler> strip is "cleaning" history 15:52:31 <Ammler> but if you strip something for the repo and someone who pulled it and pushes again, does also push that changeset. 15:52:42 <Ammler> so everyone needs to strip it too. 15:53:27 <Ammler> (everyone, who does push) 16:18:02 <Brot6> 2cctrainset: nightly compile not needed. (r228) 16:18:02 <Brot6> firs: update from r197 to r198, starting nightly compile 16:18:21 <Brot6> firs: compile done (4 errors) - http://mz.openttdcoop.org/bundles/firs/nightlies/ 16:18:21 <Brot6> fish: nightly compile not needed. (r38) 16:18:21 <Brot6> heqs: update from r160 to r167, starting nightly compile 16:18:51 <Brot6> heqs: compile completely failed! :-( - http://mz.openttdcoop.org/bundles/heqs/nightlies/compile-log/heqs-FAILED-compile-error.log 16:18:52 <Brot6> opengfx: update from r186 to r195, starting nightly compile 16:19:40 <Brot6> opengfx: compile done (0 errors) - http://mz.openttdcoop.org/bundles/opengfx/nightlies/ 16:19:40 <Brot6> opensfx: update from r38 to r40, starting nightly compile 16:20:18 <Brot6> opensfx: compile done (0 errors) - http://mz.openttdcoop.org/bundles/opensfx/nightlies/ 16:20:18 <Brot6> worldairlineset: update from r405 to r413, starting nightly compile 16:20:50 <Brot6> worldairlineset: compile done (609 errors) - http://mz.openttdcoop.org/bundles/worldairlineset/nightlies/ 16:23:29 *** andythenorth has joined #openttdcoop.devzone 16:23:35 *** openttdcoop sets mode: +v andythenorth 16:44:44 <Brot6> ::DevZone:: OpenGFX - Revision 196: Fix (r193): Comments to characters should show the correct character @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/196 (by planetmaker) 17:12:43 *** Frankr has joined #openttdcoop.devzone 17:12:48 *** openttdcoop sets mode: +v Frankr 17:14:12 <Frankr> Ammler: U there 17:14:51 <Ammler> Frankr: yes, I am 17:15:08 <Ammler> (always) 17:15:26 <Frankr> Nice Done % add on btw 17:15:52 <Frankr> Can i also ask you too look back on this chat at the compiles and tells me the number of errors on the WAS 17:15:56 <Frankr> plz 17:16:28 <Ammler> http://mz.openttdcoop.org/bundles/worldairlineset/nightlies/ <-- check it self here 17:17:00 <Frankr> It doesn't say a number though 17:17:20 <Ammler> [18:21] <Brot6> worldairlineset: compile done (609 errors) - http://mz.openttdcoop.org/bundles/worldairlineset/nightlies/ 17:17:30 <Frankr> ty 17:17:38 <Frankr> 609 errors still, thanks 17:17:45 <Ammler> the number in your project is too high ;-) 17:17:49 <Frankr> I know 17:17:58 <Ammler> well, those are mostly pure white 17:17:59 <Frankr> That is wat i am currently working on 17:18:10 <Frankr> Tha's y i wanted to kno the number 17:18:22 <Frankr> to see if it had gone down or not 17:18:32 <Ammler> you need mainly to communicate that with your drawers 17:18:51 <Frankr> I know tha's wat the set is doing 17:19:07 <Frankr> but some of them are sprite allignments, which even i can do 17:19:21 <Ammler> yes :-) 17:19:30 <Ammler> the number should at least not rise :-) 17:19:36 <Frankr> Yh 17:20:08 <Frankr> Can i also ask why these errors only started to occur after r402 17:20:27 <FooBar_> they were there before, but just not reported 17:20:37 <Ammler> not reported in the error log 17:20:46 <FooBar_> Oh, ignore that, I'm away :P 17:20:50 <Ammler> they were in the usual compile log 17:21:08 <Frankr> KK, ty 17:22:03 <Frankr> We need to fix all 609 errors before we release this, hurray for us, :) 17:22:12 <Frankr> Thnx for tha Ammler 17:22:15 <Ammler> well, that is up to you 17:22:25 <Frankr> Thy need to be fixed 17:22:51 <Ammler> in opengfx, the fix was done by Rubi in one night :-) 17:23:09 <Ammler> around 400 errros 17:23:17 <Frankr> :) 17:23:42 <Frankr> He knows wat he's doin 17:23:53 <Frankr> I leave the co-ords to beardie 17:23:55 <Ammler> in the opengfx thread is somehow a howto how to fix it 17:24:03 <Frankr> kk ty 17:24:14 <Ammler> you should create a bug report about. 17:25:57 <Frankr> done 17:28:42 <Brot6> ::DevZone:: World Airliners Set - Bug #446: Fix all Errors reported by the compile @ https://dev.openttdcoop.org/issues/446 (by Frank) 17:29:15 <FooBar_> lol "Fix all errors reported by the compile" :P 17:30:39 <Frankr> Tha's alot of Errors, :) 17:30:52 <Frankr> Most have to be done by friday 17:32:06 <LordAzamath> Anyway, why is pure white discouraged? 17:32:54 <Brot6> ::DevZone:: FIRS Industry Replacement Set - Revision 199: Feature: Junk Yard @ https://dev.openttdcoop.org/projects/firs/repository/revisions/199 (by foobar) 17:32:54 <Brot6> ::DevZone:: FIRS Industry Replacement Set - Bug #447: Set is incomplete @ https://dev.openttdcoop.org/issues/447 (by foobar) 17:33:25 <andythenorth> Do you think 447 will ever get closed then :P 17:33:40 <Frankr> :P 17:35:01 <FooBar_> eventually I hope :P 17:35:13 <LordAzamath> btw, if I worked on this concept a bit, would you want it in firs? http://www.tt-forums.net/download/file.php?id=115532 I've heard you lack a petrol station there :D 17:35:36 <FooBar_> I'm going to eat now; I'll check back on that later, LordAzamath! 17:35:42 <Frankr> Nice drawings 17:35:42 <LordAzamath> k 17:36:54 <andythenorth> LordAzamath: yes we do. Yours would need a little work :) but I think you know that. Unfortunately I've already kind of asked Irwe if he could do one... 17:37:30 <LordAzamath> oh l 17:37:32 <LordAzamath> k* 17:37:34 <LordAzamath> :D 17:37:54 <Brot6> ::DevZone:: World Airliners Set - Bug #446: Fix all Errors reported by the compile @ https://dev.openttdcoop.org/issues/446#change-1140 (by Ammler) 17:38:43 <Frankr> Thanks for them Ammler 17:40:00 <Ammler> in the tt-forums thread a bit down, DaleStan told a step-by-step howto do it 17:40:13 <Frankr> kk, ty 17:40:19 <Ammler> dunno, if Rubidium did it same way in opengfx 17:41:06 <Frankr> Well tha is very helpful 17:41:31 <Frankr> Will also determin the graphics which are miss alligned 17:41:50 <Ammler> FooBar_: andythenorth, you could use the roadmap to control the progress of firs 17:42:44 <andythenorth> Ammler: yes we could. Once the basic graphics and code are done, it's probably the best way to control adding features 17:43:20 <andythenorth> but for now these two lists are best 17:43:21 <andythenorth> http://tt-foundry.com/sets/FIRS/schema/code_status_hotlist 17:43:22 <Webster> Title: TT Foundry: Pixel Creations for Open Transport Tycoon (at tt-foundry.com) 17:43:27 <andythenorth> http://tt-foundry.com/sets/FIRS/schema/graphics_status_hotlist 17:43:28 <Webster> Title: TT Foundry: Pixel Creations for Open Transport Tycoon (at tt-foundry.com) 17:43:57 <Ammler> one ticket per not coded industry 17:44:13 <Frankr> I'm off for my tea speak later 17:46:18 <andythenorth> Ammler: that would be a nice idea - but I'm not fancying adding the tickets. Feel free if you would like to... 17:49:24 <Ammler> well, it would be more helpful then the ticket #447 17:50:31 <planetmaker> :-D 17:50:34 <planetmaker> indeed 17:50:56 <Ammler> but defining the name of the first release version and such is up2managers 17:51:20 <Ammler> maybe 0.1.0-alpha :-) 17:52:03 <planetmaker> 19:31] <LordAzamath> Anyway, why is pure white discouraged? <-- it doesn't fade out when the screen fades to black, e.g. when showing high score chart 17:52:33 <LordAzamath> hmph 17:52:38 <LordAzamath> that 17:52:40 <LordAzamath> s 17:52:49 <LordAzamath> rather openttd bug, isn't it? 17:52:59 <LordAzamath> as pure white is a part of the palette 17:53:00 <planetmaker> no. It's this way since TTD 17:53:05 <LordAzamath> well 17:53:07 <LordAzamath> ttd bug 17:53:23 <LordAzamath> which could/should be fixed 17:53:28 <Ammler> pure white is grf drawer bug 17:53:50 <Ammler> as the other white is white enough, there is no pure white in nature ;-) 17:56:55 <Ammler> hmm, I am too stupid to disable postfix accepting mails from extern but still use it for the devzone 18:04:03 <Brot6> firs: Backup push to ssh://hg@bitbucket.org/firs/firs/ initiated. 18:04:11 <Brot6> opengfx: Backup push to ssh://hg@bitbucket.org/OpenTTD/opengfx/ initiated. 18:10:19 <FooBar_> I already put milestone-versions in the FIRS roadmap a while ago; which I changed a bit yesterday 18:11:38 <FooBar_> I figured that we don't do releases before al industries are in, and at that point the set should be playable. 18:11:47 <FooBar_> We can discuss the versioning scheme though 18:12:08 <FooBar_> I didn't include alpha-versions, although maybe we should 18:13:20 <FooBar_> That depends whether we want to call an intermediate version that doesn't meet our final criteria yet an alpha or a stable release. 18:13:36 <Ammler> hmm, milestone looks like alpha 18:13:42 <FooBar_> In my current scheme, I considered those 'stable' 18:14:05 <Ammler> what is earlier? 18:14:07 <FooBar_> milestone indeed is some sort of alpha, but should not be released as a release IMO 18:14:22 <FooBar_> first the milestones, then the same version number without suffix 18:14:34 <Ammler> hmm, wrong sorted 18:15:15 <FooBar_> true 18:16:26 <FooBar_> It would sort -alpha suffixes wrong as well by the way 18:16:39 <Ammler> yes 18:18:34 <Ammler> it looks like it does sort with date, then name 18:18:45 <Ammler> well, how else should it be done? 18:18:55 <FooBar_> probably, but I don't want to go as far as assigning dates :P 18:19:05 <Ammler> I wouldn't either 18:19:56 <Ammler> -stable ? 18:19:58 <FooBar_> alphabetically it's sorted completely correct, it's just that the milestone (or alpha) occurs before the stable release with that version number 18:20:23 <FooBar_> that could work very well :) I'll add those suffixes right away! 18:20:35 <Ammler> you can remove it, if you have reached it and tag 18:21:24 <FooBar_> yes indeed 18:21:33 <FooBar_> hmmmz "0.0.0-stable" :P 18:21:42 <FooBar_> how stable would version 0 be exactly? :P 18:22:32 <FooBar_> oh well, the list sorts nicely now 18:23:01 <Ammler> hehe 18:23:27 <Ammler> as I said, if you reach it, you can add the date and remove the suffix 18:23:42 <FooBar_> yep :) 18:24:02 <planetmaker> ha, nice. I found a way to set my personal testing dir into my personal .hgignore so that I won't commit that change anymore :-) 18:24:20 <planetmaker> *change to .hgignore 18:24:33 <Brot6> ::DevZone:: OpenGFX - Revision 197: Cleanup: bring a bit order into .hgignore and comment it a bit more @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/197 (by planetmaker) 18:26:08 <FooBar_> Thumbs.db is not really a Mac file :P 18:27:17 <FooBar_> but then any sane windows user disables the creation of that file altogether 18:27:18 <Ammler> we should somewhere store example for local ignore files 18:27:41 <Ammler> FooBar_: tell that the was guys ;-) 18:28:11 <FooBar_> was guys: you should disable the creation of thumbs.db files in the Folder Options dialog 18:28:30 <Ammler> :-) 18:28:38 <Ammler> Frankr: ^ 18:28:50 <Ammler> (the only one here) 18:28:54 <FooBar_> hehehe 18:29:14 <FooBar_> maybe you can add a hook that denies commits with a thumbs.db file in it :P 18:29:15 <Ammler> btw, and you missed the following in the IRC: 18:29:30 <Ammler> [18:19] <Brot6> heqs: compile completely failed!  - http://mz.openttdcoop.org/bundles/heqs/nightlies/compile-log/heqs-FAILED-compile-error.log 18:29:53 <FooBar_> I didn't miss that... That's not my set :P 18:29:54 <Ammler> !s/and/andythenorth/ 18:30:18 <FooBar_> so I ignored it... 18:30:19 <Ammler> autocompletation didn't work :-) 18:30:46 <planetmaker> Ammler: it's part of your .hgrc 18:31:10 <planetmaker> and I only added one directory which I decided to use for stuff related to the project but not committed: testing 18:31:30 <Ammler> planetmaker: what are you talking about? 18:31:38 <planetmaker> FooBar_: there's nothing wrong IMO with having that file. But having it in the repo is wrong ;-) 18:31:53 <planetmaker> Ammler: about my .hgignore. Not the repository one's 18:32:13 <Ammler> oh, it is ok to have them also in repo ignroe 18:32:22 <FooBar_> IMO the file is wrong as well; it just eats disk space without adding much benefit. Generating thumbnails on the fly is a matter of milliseconds on modern computers 18:32:27 <Ammler> as some might have troubels to setup a local ignore file 18:32:38 <planetmaker> FooBar_: depends upon the number of images 18:32:46 <Ammler> but it would help those people to use it. 18:32:52 <Ammler> I btw. prefer regex ignore 18:33:03 <Brot6> ::DevZone:: Generic NewGRF Makefile - Revision 24: Cleanup: bring a bit order into .hgignore and comment it a... @ https://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/24 (by planetmaker) 18:33:07 <planetmaker> Ammler: well... the usual ones. But everyone has different preferences to naming and sorting things 18:33:21 <planetmaker> I prefer glob :-P 18:33:34 <planetmaker> easier to understand :-) 18:33:48 <planetmaker> aeolusreloaded:~/ottd/grfdev/newgrf_makefile ingo$ cat ~/.hgrc 18:33:49 <planetmaker> [ui] 18:33:51 <planetmaker> username = planetmaker <ottd@planetmaker.de> 18:33:52 <planetmaker> ignore = ~/.hgignore 18:33:54 <planetmaker> aeolusreloaded:~/ottd/grfdev/newgrf_makefile ingo$ cat ~/.hgignore 18:33:56 <planetmaker> syntax: glob 18:33:56 <Ammler> hmm, not sure, it didn't work for me, maybe because I forgot to define it. 18:33:58 <planetmaker> testing 18:34:08 <FooBar_> planetmaker: nah, even my holiday pictures dir with 2742 items loads the thumbs very quickly. It only loads those that are in the current view anyways. 18:34:09 <planetmaker> glob is default, I think 18:34:19 <Ammler> afaik, regex is default :-) 18:34:26 <planetmaker> well, maybe :-) 18:35:02 <planetmaker> ^^ there I pasted my personal setup. Quite convenient :-) 18:36:13 <Ammler> [ui] 18:36:15 <Ammler> ignore.global = ~/.hgignore 18:38:00 <Ammler> well, I don't need a local hgignore 18:38:08 <Ammler> as I wouldn't use hg ci -A 18:38:54 <planetmaker> -A ? 18:39:51 <planetmaker> I don't use that either. But having a constantly modified .hgignore put me off. 18:40:15 <planetmaker> after all I don't want to spam the repo with my personal crap :-P 18:40:57 <Ammler> that only happens if you use hg add without thinking 18:44:52 <Brot6> ::DevZone:: HEQS Heavy Equipment Set - Revision 168: Add: pcx file for 20xx (Wolfpen Ridge) Dump Truck @ https://dev.openttdcoop.org/projects/heqs/repository/revisions/168 (by andythenorth) 18:45:04 <andythenorth> d:) 18:45:19 <Ammler> :-) 18:46:06 <Ammler> those you break the compile should pay something in the coffee bucket 18:46:38 <Ammler> !s/you/who/ 18:47:13 <andythenorth> what is this !s business? 18:47:24 <andythenorth> is it a C thing? 18:47:26 <Ammler> sed replace 18:47:37 <andythenorth> I can see roughly what it does 18:47:49 <andythenorth> (googling) 18:47:54 <Ammler> well, it doesn't work here :-) 18:48:09 <Ammler> but you have sed on your mac box 18:48:19 <Ammler> man sed 18:48:36 <andythenorth> yup 18:49:37 <Ammler> we could create a paypal account and if someone breaks the compile, he has to donate 5€ 18:50:02 <Ammler> we would have already 15€ there ;-) 18:50:10 <Ammler> 10 from Frankr 18:53:43 <Ammler> btw. planetmaker what is now with CFLF issue? 18:53:54 <Ammler> do we solve it with makefile or with zip? 18:56:45 <FooBar_> I believe we opted for CF only? 18:57:08 <Brot6> ::DevZone:: #openttdcoop - Revision 32: [CF] Change: bundle url @ https://dev.openttdcoop.org/projects/home/repository/revisions/32 (by Ammler) 18:57:08 <Brot6> ::DevZone:: FIRS Industry Replacement Set - Revision 200: Fix: remove pure white pixels from sprites (closes ... @ https://dev.openttdcoop.org/projects/firs/repository/revisions/200 (by foobar) 18:57:08 <Brot6> ::DevZone:: FIRS Industry Replacement Set - Bug #425 (Closed): pure white pixels @ https://dev.openttdcoop.org/issues/425#change-1143 (by foobar) 19:10:57 <Ammler> [20:57] <FooBar_> I believe we opted for CF only? <-- did we? I would have disagreed :-) 19:11:15 <Ammler> IMO, we need to support the windows newbie there. 19:11:34 <FooBar_> I might be mistaken, hence the question mark ;) 19:11:34 <Ammler> ah, of course, the files on the repo should be CF only. 19:11:54 <FooBar_> ah, then I'm confused by that I think 19:12:04 <Ammler> but the the release zip should have txt files with CFLF. 19:20:10 <FooBar_> well, then you need that ZIP stuff I guess 19:20:20 <Brot6> ::DevZone:: #openttdcoop - replacepurewhite.atn @ https://dev.openttdcoop.org/attachments/download/322/replacepurewhite.atn (by foobar) 19:20:20 <Brot6> ::DevZone:: #openttdcoop - Document: Photoshop Action to Remove Pure White Pixels from Sprites @ https://dev.openttdcoop.org/documents/10 (by foobar) 19:21:07 <FooBar_> Frankr: ^ you might want that: https://dev.openttdcoop.org/documents/10 19:22:40 <Frankr> just as i get bk, lol 19:23:39 <Frankr> FooBar_: Can't access it 19:23:58 <FooBar_> that's odd... 19:24:01 <FooBar_> let me see... 19:24:30 <FooBar_> should be public, that 19:24:55 <Frankr> says i'm not autorised 19:25:10 <Frankr> authorised* 19:25:20 <FooBar_> Weird, I can even view it without being logged in :S 19:25:22 <Brot6> ::DevZone:: World Airliners Set - Bug #446: Fix all Errors reported by the compile @ https://dev.openttdcoop.org/issues/446#change-1144 (by foobar) 19:26:18 <FooBar_> maybe check again later? 19:26:33 <Ammler> he? 19:27:02 <FooBar_> I added it to your issue, so you should be able to find it later ;) 19:27:47 <Frankr> k, ty 19:28:33 <Ammler> Frankr: please, try again 19:28:43 <Ammler> it might be a bug of my roles config 19:28:56 <Ammler> well, it would be silly 19:30:00 <Frankr> ok 19:30:10 <Frankr> fine now 19:30:17 <Ammler> good 19:31:01 <Ammler> that is silly, a registered user could have less access then public 19:31:26 <Frankr> lol 19:32:07 <Ammler> but fixed now :-) 19:32:12 <Frankr> Sorted now tho, :) 19:32:38 <Frankr> Problem with this is i don't have photoshop 19:33:05 <Frankr> :p 19:34:04 <Frankr> I suppose i can get it off beardie tho 2morro 19:34:19 <Ammler> what do you use to manipulate graphics? 19:34:20 <Ammler> gimp? 19:34:43 <Ammler> that is explained by dalestan in the forums thread of opengfx 19:36:16 <Frankr> Gimp yh 19:37:10 <Frankr> Oh yh, forgot 19:37:58 <Frankr> Ammler: How do you work out which plane needs changing 19:38:20 <Frankr> And btw wat is this about me owing 10Euro's lol 19:39:02 <planetmaker> arg. This leet-speak is hardly readable :S 19:39:11 <Ammler> Frankr: for now, but those 10€ in a box and lable it for #openttdcoop 19:39:18 <Ammler> we need first to create the account 19:39:31 <planetmaker> buy Ammler a beer :-) 19:39:40 <Ammler> but a expensive one :P 19:39:53 <planetmaker> Switzerland IS expensive ;-) 19:39:57 <Ammler> with a dancing girl maybe :-) 19:40:02 <planetmaker> lool 19:40:31 <Ammler> well, then we might need some more failed compiles 19:40:38 <planetmaker> concerning CL / CL CR... the only thing really decided was to change the repo 19:41:00 <Ammler> FooBar_: should run dos2unix before commit 19:41:09 <FooBar_> Frank: check the error log, it says what sprite has white pixels in it. Then open the compiled NFO file and look up the sprite number you found in the error log. This tells you the pcx file that has the white pixel in it. But it doesn't really hurt to execute the action on all pcx files 19:41:42 <Ammler> you could just run that over all files 19:41:49 <Ammler> if it fails, hg revert :-) 19:41:54 <FooBar_> Ammler: I'm (hopefully) running hgext.win32text before commit 19:42:07 <Ammler> FooBar_: hook? 19:42:14 <FooBar_> no, just an extension 19:42:26 <Ammler> but how is it triggered? 19:42:26 <FooBar_> http://mercurial.selenic.com/wiki/Win32TextExtension 19:42:27 <Webster> Title: Win32TextExtension - Mercurial (at mercurial.selenic.com) 19:42:52 <FooBar_> How it actually works? I don't have a clue. I just followed the steps from that page 19:43:12 <Frankr> FooBar_: You know that would be a hell of alot of pcx files, :) 19:44:06 <Ammler> FooBar_: you added also **.csv? 19:44:23 <FooBar_> Frankr: I know, but Photoshop has a Batch function for that ;) 19:44:31 <Frankr> I don't have Photoshop 19:44:37 <FooBar_> Ammler: yes, I did. And **.txt and **.pnfo 19:45:07 <FooBar_> Frankr: I know, but you said that Beardie had it. Let him run it ;) 19:45:36 <Frankr> :) 19:45:39 <Ammler> FooBar_: maybe worth to add that extension to the setup guide? 19:45:54 <FooBar_> It's not mandatory to use that action and/or photoshop. If you can do something similar with GIMP then by all means do so. It's just that I happen to have Photoshop and not GIMP 19:45:59 <Frankr> Ty for tha FooBar i'll get him to do it 19:46:14 <planetmaker> Frankr: guess what Rb did for the OpenGFX pcx files? 19:46:19 <planetmaker> that were quite some, too 19:46:25 <FooBar_> Frankr: you're welcome :) 19:46:31 <planetmaker> and surely he used gimp 19:46:39 <Ammler> planetmaker: he did that manually :-) 19:46:45 <planetmaker> or like that 19:46:57 <Ammler> well, my guess. 19:46:58 <FooBar_> Ammler: yes, that might be worth. I added the page to my bookmarks, I just haven't gotten around adding it to the guide yet. But I will in due time ;) 19:47:00 <planetmaker> but I guess not by hex editing 19:47:07 <Ammler> manually doesn't need to be slower. 19:47:30 <FooBar_> Depends on the amount of files... 19:47:47 <Ammler> of course, quite a lot different on was, I guess. 19:48:40 <FooBar_> If there's like 20 or more files, batch conversion would do it in 20 seconds for you, while manually you'd need more like 20 minutes 19:49:57 <FooBar_> But then by all means, one should do things the way one wants to do them. I'm merely providing something I conceived, as it might be useful to others :) 19:52:33 <Frankr> Sure is 19:55:18 <Brot6> ::DevZone:: #openttdcoop - Revision 33: [CF] Fix: don't output changeset from last compile in the changelog a... @ https://dev.openttdcoop.org/projects/home/repository/revisions/33 (by Ammler) 19:55:18 <Brot6> ::DevZone:: World Airliners Set - Bug #448: Remove Pure White Pixels from Sprites @ https://dev.openttdcoop.org/issues/448 (by Beardie27) 19:55:18 <Brot6> ::DevZone:: OpenGFX - Revision 198: Fix: Added the source png, which was used to convert from 32bpp to 8bpp (... @ https://dev.openttdcoop.org/projects/opengfx/repository/revisions/198 (by Ammler) 19:55:18 <andythenorth> FooBar_: Junk Yard FTW. Looking at it in game now ;) 19:55:19 <Brot6> ::DevZone:: World Airliners Set - Bug #448 (Rejected): Remove Pure White Pixels from Sprites @ https://dev.openttdcoop.org/issues/448#change-1147 (by Beardie27) 19:56:01 <Rubidium> Ammler/Frank: I did look at the logs and checked the sprites manually, not DaleStan's "should" work strategy; that way it's quite uncheckable 19:56:18 <FooBar_> andythenorth: nice :) I think the heaps of junk need to be bigger. Unfortunately that's the hardest part to draw... :( 19:56:25 <Rubidium> LordAzamath: white pixels warnings are bad because they hide the correct warnings 19:57:21 <Ammler> actually they are mostly ignored by everyone until EdorFaus mentioned it. 19:57:33 <Rubidium> LordAzamath: e.g. look at OGFX bugs 367, 368 and 369 19:57:39 <planetmaker> yeah, but it was always a zillion warnings... 19:57:48 <Ammler> you fixed those, when someone reported the white bars as glitch. 19:57:49 <Frankr> I don't think i'll do that Rubudium 19:57:52 <planetmaker> I dislike pointless warnings :-) 19:58:10 <planetmaker> Frankr: your choice, your newgrf, your bugs which you'll have a harder time to find :-) 19:58:31 <andythenorth> If we're going to eliminate this white pixel problem, we need to either (a) remove them from *source* not pcx files or (b) agree not to care and suppress the warnings 19:58:34 <andythenorth> I favour b 19:58:46 <andythenorth> life is short, we spend enough of it on TTD 19:58:58 <andythenorth> pointless warnings are bad Andons 19:59:12 <andythenorth> http://en.wikipedia.org/wiki/Andon_(manufacturing) 19:59:38 <Ammler> Frankr: well, prio "immediate" might be a bit hight ;-) 19:59:52 <Frankr> Lol 19:59:59 <Rubidium> andythenorth: but... fixing the warnings for OGFX has fixed at least 3 distinct bugs, so the warnings have proven themselves useful 20:00:24 <planetmaker> ^^ :-) 20:00:24 *** Beardie has joined #openttdcoop.devzone 20:00:29 *** openttdcoop sets mode: +v Beardie 20:00:41 <andythenorth> bugs caused by white pixels? Or bugs discovered during the process of finding white pixels? 20:00:43 <planetmaker> and there comes the person who rejected this all 20:00:47 <Beardie> Hello 20:00:58 <planetmaker> hi 20:01:01 <Beardie> rejected what? 20:01:09 <Ammler> andythenorth: the best alternative, if you don't want to fix them, you can at least check, they don't rise. 20:01:10 <Beardie> the white pixels yes 20:01:16 <Beardie> i blame...... 20:01:19 <Beardie> DJ 20:01:21 <Beardie> lol 20:01:25 <Beardie> for not telling me about it 20:01:26 <Ammler> planetmaker: he didn't 20:01:31 <Ammler> it was double 20:01:34 <Beardie> becuase i hadn't a clue 20:01:56 <Ammler> https://dev.openttdcoop.org/issues/446 20:02:01 <planetmaker> :-P 20:02:16 <Beardie> i know ammler 20:02:24 <Ammler> that was for pm :-) 20:02:39 <planetmaker> ok, then I'll save my perrogative comment for a more suitable occasion :-P 20:02:43 <Beardie> o lol 20:03:00 <planetmaker> *pejorative - or whatever 20:03:13 <Ammler> Beardie: you should comment, why you reject 20:03:16 <Rubidium> andythenorth: if the sprites wouldn't have had white pixels, grfcodec would have warned ONLY about white pixels in each of the bugs 367, 368 and 369. 20:03:22 <Beardie> comment? 20:03:35 <Ammler> the reason, why you rejected a issue. 20:03:55 <Beardie> i made a issue for it then not realising you had 20:04:02 <Beardie> so i got rid of mine 20:04:03 <Ammler> like Dublicate: https://dev.openttdcoop.org/issues/446 20:04:12 <andythenorth> Hmm. There are problems we fix because they damage game play. There are problems we fix because they damage maintainable code. There are problems we fix because we love tinkering and crafting beautiful things. White pixels fulfils none of those criteria for me, so I'm ignoring them. I'm in favour of suppressing that warning if possible. 20:04:29 <Beardie> indeed 20:04:29 <andythenorth> If there is a player out there who cares, let them open the source, fix the pixels :D 20:04:41 <Beardie> it doesn;t effect the game though? 20:04:50 <Beardie> so why have a error saying there are white pixels 20:05:07 <planetmaker> andythenorth: uhm... it damages maintainable code by that definition 20:05:15 <Rubidium> andythenorth: you mean GRFcodec shouldn't warn because of wrong offsets/sizes of sprites in your nfo w.r.t. to the pcx? 20:05:51 <andythenorth> Yup it should - useful 20:05:58 <andythenorth> White pixels: not useful 20:05:59 <planetmaker> then go and fix your white pixels 20:06:10 <Rubidium> andythenorth: that is *exactly* what the white pixels are about 20:06:14 <planetmaker> what else do you think an offset error shows by?! 20:06:15 <Ammler> andythenorth: removing those pure white errors solved 3 "real" bugs, isn't that worth? 20:06:31 <andythenorth> Ok, so I get the issue in that case. 20:06:33 <andythenorth> grok, as we say 20:06:36 <Ammler> 3 real gameplay bugs 20:07:54 <Frankr> Lol, this problem has really turned out into a debate 20:08:27 <Rubidium> maybe the warning should be made more clear 20:08:41 <Beardie> indeed i had no clue about them 20:09:23 <andythenorth> I had previously only seen the white pixels 'problem' described in the context of fading the screen to black. (By DaleStan I believe) 20:09:23 <Rubidium> -> there are N white pixels in sprite Y. This can mean that the offset/size of the sprite in the nfo are incorrect. White pixels also breaks TTD(P)'s fade-to-black feature. 20:09:44 <Ammler> almost nobody was aware of those, else you wouldn't have so many bug reports in tt-forums about white bars. 20:10:28 <LordAzamath> errrr.. I blame... him 20:10:40 <LordAzamath> oh, wrong channel 20:10:41 <LordAzamath> :D 20:11:14 <andythenorth> bah. Now I'll have to go and fix Zephyris' cargo graphics :| 20:11:33 <Ammler> :-) 20:11:44 <LordAzamath> fix openttd 20:11:44 <Ammler> well, maybe he would like to do that self 20:11:57 <Ammler> LordAzamath: what would you fix there? 20:12:04 <andythenorth> well I used them in HEQS 20:12:05 <LordAzamath> dunno.. just fix 20:12:10 <Frankr> Well atm we have our graphics guys doin all the flashes and coders doing the white pixel problem 20:12:32 <LordAzamath> mta 1.0 is going to be released tomorrow 20:12:34 <Ammler> LordAzamath: removing pure white isn't a workaround. 20:12:36 <FooBar_> andythenorth: check my Photoshop Action; it can do all for you. Dunno if it works on layers, but I could add that feature :) 20:12:44 <andythenorth> LordAzamath: I wish IRC had the hammer smacking head emoticon 20:12:47 <andythenorth> FooBar_: sounds useful 20:12:55 <LordAzamath> I wasn't about white pixels 20:12:57 <LordAzamath> :D 20:13:02 <LordAzamath> just randomly saying stuff 20:13:07 <andythenorth> ok 20:13:12 <Ammler> Frankr: important is that graphics guys don't make new stuff with it. 20:13:23 <LordAzamath> y'know, to get a feeling I'm a part of the conversation :D 20:13:24 <FooBar_> andythenorth: https://dev.openttdcoop.org/documents/10 20:13:35 <Frankr> Yh it is Ammler 20:41:27 *** ODM has quit IRC 20:46:45 *** LordAzamath has quit IRC 20:46:46 *** Beardie has quit IRC 20:54:23 <Brot6> ::DevZone:: World Airliners Set - Revision 414: Il62 is finally coded in @ https://dev.openttdcoop.org/projects/worldairlineset/repository/revisions/414 (by Frank) 20:57:07 *** LordAzamath has joined #openttdcoop.devzone 20:57:12 *** openttdcoop sets mode: +v LordAzamath 21:09:01 *** andythenorth has quit IRC 21:20:49 <Brot6> ::DevZone:: World Airliners Set - Revision 415: Changes to a couple IL62 files @ https://dev.openttdcoop.org/projects/worldairlineset/repository/revisions/415 (by Frank) 21:25:36 <Brot6> ::DevZone:: OpenSFX - Feature #397: Sample 40: Sawmill @ https://dev.openttdcoop.org/issues/397#change-1150 (by Roujin) 21:28:17 *** LordAzamath has quit IRC 21:48:58 *** Frankr has quit IRC 21:51:42 *** Frankr has joined #openttdcoop.devzone 21:51:47 *** openttdcoop sets mode: +v Frankr 22:04:04 <Brot6> firs: Backup push to ssh://hg@bitbucket.org/firs/firs/ initiated. 22:04:11 <Brot6> heqs: Backup push to ssh://hg@bitbucket.org/firs/heqs/ initiated. 22:04:18 <Brot6> opengfx: Backup push to ssh://hg@bitbucket.org/OpenTTD/opengfx/ initiated. 22:13:22 <Frankr> bk 22:44:10 <Brot6> ::DevZone:: World Airliners Set - Revision 416: Fix #443 Replaced RyanAir and Thomson 738 png and pcx files @ https://dev.openttdcoop.org/projects/worldairlineset/repository/revisions/416 (by Frank) 22:44:10 <Brot6> ::DevZone:: World Airliners Set - Feature #443 (Closed): Implement New Ryan Air 737-800 and fixed Thomson 737... @ https://dev.openttdcoop.org/issues/443#change-1153 (by Frank) 22:46:48 <Rubidium> I hope you did randomise passenger profit for those Ryan Air planes ;) 22:51:10 <Frankr> :) 23:32:48 <Frankr> I'm off cya 23:33:03 *** Frankr has quit IRC 23:58:01 <Brot6> ::DevZone:: OpenGFX - Bug #280: standard signals @ https://dev.openttdcoop.org/issues/280#change-1154 (by bilbo)