Log for #openttdcoop.devzone on 16th August 2009:
Times are UTC Toggle Colours
00:08:04  <Brot6> ::DevZone:: OpenSFX - Feature #397: Sample 40: Sawmill @ (by Roujin)
00:14:56  <Brot6> ::DevZone:: OpenSFX - Feature #397: Sample 40: Sawmill @ (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. (... @ (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 @ (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> <- 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... @ (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 ... @ (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... @ (by planetmaker)
09:10:08  <Brot6> ::DevZone:: OpenSFX - Revision 40: Feature [Makefile]: target 'release_source' allows to distribute source fo... @ (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> <- 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... @ (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:// initiated.
10:04:11  <Brot6> opensfx: Backup push to ssh:// 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>
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 @ (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>
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_>
11:40:03  <Webster> Title:  blog  archive  mercurial needs better end-of-line support (at
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>
11:42:21  <Webster> Title: Win32TextExtension - Mercurial (at
11:46:49  <Rubidium> <- 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> <- 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 ... @ (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>
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>
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 @ (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> <- 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... @ (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> <- 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> <-- that is what I run to skip the pseudo sprites
13:07:56  <Rubidium> yay, found the culprit ;)
13:08:09  <Ammler> Rubidium: <-- 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
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 ... @ (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> <-- 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 @ (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) -
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! :-( -
16:18:52  <Brot6> opengfx: update from r186 to r195, starting nightly compile
16:19:40  <Brot6> opengfx: compile done (0 errors) -
16:19:40  <Brot6> opensfx: update from r38 to r40, starting nightly compile
16:20:18  <Brot6> opensfx: compile done (0 errors) -
16:20:18  <Brot6> worldairlineset: update from r405 to r413, starting nightly compile
16:20:50  <Brot6> worldairlineset: compile done (609 errors) -
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 @ (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> <-- 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) -
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 @ (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 @ (by foobar)
17:32:54  <Brot6> ::DevZone:: FIRS Industry Replacement Set - Bug #447: Set is incomplete @ (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? 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 @ (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>
17:43:22  <Webster> Title: TT Foundry: Pixel Creations for Open Transport Tycoon (at
17:43:27  <andythenorth>
17:43:28  <Webster> Title: TT Foundry: Pixel Creations for Open Transport Tycoon (at
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:// initiated.
18:04:11  <Brot6> opengfx: Backup push to ssh:// 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 @ (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!  -
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... @ (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 <>
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> = ~/.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 @ (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 @ (by Ammler)
18:57:08  <Brot6> ::DevZone:: FIRS Industry Replacement Set - Revision 200: Fix: remove pure white pixels from sprites (closes ... @ (by foobar)
18:57:08  <Brot6> ::DevZone:: FIRS Industry Replacement Set - Bug #425 (Closed): pure white pixels @ (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 @ (by foobar)
19:20:20  <Brot6> ::DevZone:: #openttdcoop - Document: Photoshop Action to Remove Pure White Pixels from Sprites @ (by foobar)
19:21:07  <FooBar_> Frankr: ^ you might want that:
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 @ (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_>
19:42:27  <Webster> Title: Win32TextExtension - Mercurial (at
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... @ (by Ammler)
19:55:18  <Brot6> ::DevZone:: World Airliners Set - Bug #448: Remove Pure White Pixels from Sprites @ (by Beardie27)
19:55:18  <Brot6> ::DevZone:: OpenGFX - Revision 198: Fix: Added the source png, which was used to convert from 32bpp to 8bpp (... @ (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 @ (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>
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>
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:
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:
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 @ (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 @ (by Frank)
21:25:36  <Brot6> ::DevZone:: OpenSFX - Feature #397: Sample 40: Sawmill @ (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:// initiated.
22:04:11  <Brot6> heqs: Backup push to ssh:// initiated.
22:04:18  <Brot6> opengfx: Backup push to ssh:// 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 @ (by Frank)
22:44:10  <Brot6> ::DevZone:: World Airliners Set - Feature #443 (Closed): Implement New Ryan Air 737-800 and fixed Thomson 737... @ (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 @ (by bilbo)

Powered by YARRSTE version: svn-trunk