Log for #openttdcoop.devzone on 25th March 2010:
Times are UTC Toggle Colours
00:35:18  *** KenjiE20 has quit IRC
01:32:34  *** OwenS has quit IRC
02:13:21  *** DJNekkid has quit IRC
02:25:11  *** DJNekkid has joined #openttdcoop.devzone
07:09:27  <planetmaker> good morning
07:17:12  *** ODM has joined #openttdcoop.devzone
09:03:34  *** OwenS has joined #openttdcoop.devzone
09:15:57  *** ODM has quit IRC
09:33:02  <andythenorth> planetmaker: templates.....
09:33:19  <andythenorth> (i) where do you guys want them kept?  (ii) do they get added to a dep check automatically?
09:37:35  <planetmaker> andythenorth, templates best fit into a separate sub-folder like sprites/nfo/templates
09:38:29  <planetmaker> The dep check checks for all file types which are named in Makefile.config:
09:38:42  <planetmaker> FILE_SRC_EXTENSIONS = pnfo template
09:38:46  <planetmaker> FILE_INC_EXTENSIONS = wav pcx
09:39:09  <planetmaker> Templates would need adding to FILE_SRC_EXTENSION
09:39:23  <planetmaker> as they can include further files (which wav and pcx files cannot)
09:39:50  <planetmaker> Thus FIRS currently checks for *.pnfo and *.template files
09:39:57  <planetmaker> It might be worth to add  *.tnfo
09:40:55  <andythenorth> do you think I should?  There are currently no templates in HEQS so it would be nice to set it up correctly
09:41:18  <planetmaker> Well, it depends on how you name your template files
09:41:36  <planetmaker> Initially, I think, I used in some projects *.template. But I meanwhile like *.tnfo better
09:42:12  <planetmaker> If there's no template yet: add tnfo to FILE_SRC_EXTENSIONS and create a dir sprites/nfo/templates
09:42:25  <planetmaker> where you put those template files
09:42:32  <planetmaker> Sounds like the cleanest solution to me
09:46:12  <andythenorth> planetmaker: any reason not to have sprites/templates?  Same as FIRS...
09:47:21  <planetmaker> That's also a place. But FIRS uses sprites/nfo/templates
09:47:47  <planetmaker> and templates are usually nfo of some kind
09:48:10  <andythenorth> FIRS has no sprites/nfo/templates :)
09:48:26  <planetmaker> uhm... no?
09:48:40  <andythenorth> does that explain why a template I added to FIRS seems to be missed by the dep check?
09:48:40  <planetmaker> it has here
09:49:01  <planetmaker> ~/ottd/grfdev/firs> ls sprites/nfo/templates/
09:49:01  <planetmaker> ~template_primary_action23_cargoacceptance.pnfo
09:49:01  <planetmaker> template_primary_action23_cargoacceptance.pnfo
09:49:23  <andythenorth> check the remote repo:
09:49:33  <planetmaker> hm, but it's not tracked, true :-)
09:50:03  <planetmaker> but there's no sprites/templates either :-)
09:50:03  <andythenorth> I actually prefer it in sprites/templates
09:50:23  <andythenorth> true. it's just in root
09:50:30  <andythenorth> I prefer it *not* in nfo
09:50:36  <andythenorth> easier to navigate on the mac keyboard
09:50:44  <planetmaker> uh? How that?
09:51:00  <andythenorth> actually maybe not
09:51:28  <andythenorth> should I move the FIRS location to sprites/nfo/templates then?
09:51:32  <andythenorth> I can do a find replace
09:51:43  <Ammler> nfo code belongs to sprites/nfo ;-)
09:52:02  <planetmaker> It's not something crucial tbh. It would fit in either sprites/templates or sprites/nfo/templates a bit better, though
09:52:23  <planetmaker> EXTRA_DIRS         := templates
09:52:23  <planetmaker>  <-- it would render that line void in Makefile.config
09:52:47  <planetmaker> as sub dirs of sprites are automatically handled by dir detection when it comes to bundling the source
09:53:01  <Ammler> sprites/templates sounds like a location for the image templates
09:53:24  <Ammler> (png or pcx or psd or whatever you use)
09:53:36  <andythenorth> it's easier for my brain to have all my projects follow the same structure
09:53:43  <andythenorth> but changing FIRS == work
09:53:51  <andythenorth> and it's not
09:54:02  <Ammler> so because FIRS is wrong, other projects have to be wrong, either?
09:54:15  <Ammler> does that make FIRS more right? ;-)
09:54:32  <planetmaker> andythenorth, for a new project I wouldn't recommend ./templates
09:54:40  <planetmaker> But one of the two variants mentioned above
09:54:55  <planetmaker> And having that dir there or there - what difference does it make?
09:54:57  <andythenorth> Ammler: do you want to move the FIRS templates directory?  I wouldn't mind :)
09:55:19  <planetmaker> andythenorth, it would seem proper, but very low priority
09:55:42  <planetmaker> but if you start something new: do the conceptionally  better way :-)
09:56:08  <andythenorth> and also refactor other stuff for cognitive ease, if possible :)
09:57:19  <Ammler> andythenorth: don't ask such things, I have practice in big code changes ;-)
09:58:15  <planetmaker> hehe... you started big code changes in OpenGFX :-)
09:58:21  <planetmaker> And honestly: they were good
09:58:59  <Ammler> well, disadvantage is the history lost
09:59:13  <planetmaker> not really. History is there. Just in different files
09:59:36  <Ammler> well, annotate doesn't work anymore...
09:59:52  <planetmaker> well, it does :-) - but only back to the change
10:00:05  <planetmaker> No real show stopper
10:00:46  <Ammler> yeah, I agree, just mention that not everything on file moving/splitting is good
10:10:14  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 244: Add: empty template file for Industrial Trams <> || HEQS "Heavy Equipment" Set - Revision 243: Change: support for changing properties on refit for... <> || Redmine - Revision 3454: Escape href attribute in auto links (#5179). <> || Redmine - Revision 3453: Fixes permission check in QueriesController (#5181). <>
10:26:17  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 245: Change: renamed file <>
10:42:19  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 248: Change: use more defines in tram wagon template <> || HEQS "Heavy Equipment" Set - Revision 247: Fix: mistake with word/byte confusion in industrial ... <> || HEQS "Heavy Equipment" Set - Revision 246: Changed: moved action 2/3 code to template for tram ... <>
10:46:57  *** OwenS has quit IRC
10:58:21  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 249: Change: improved formatting, more defines in tram wa... <>
11:29:19  *** KenjiE20 has joined #openttdcoop.devzone
11:29:27  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 252: Change: restructured some ation 2 for tram locomotiv... <> || HEQS "Heavy Equipment" Set - Revision 251: Change: industrial tram locomotives use templates <> || HEQS "Heavy Equipment" Set - Revision 250: Add: template for industrial tram locomotives <>
11:44:26  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 253: Change: tidied varact 2 chain for tram locomotive <>
12:14:55  *** ODM has joined #openttdcoop.devzone
12:16:32  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 254: Remove: un-needed tram wagon template <>
12:48:37  <Webster> Latest update from devactivity: Nutracks - Bug #865 (New): Track costs are inconsistent and exploitable <> || HEQS "Heavy Equipment" Set - Revision 255: Change: refit / length / position set for Industrial... <>
13:07:56  <planetmaker> @base 10 16 16
13:07:56  <Webster> planetmaker: 10
13:08:14  <planetmaker> @base 16 10 1F
13:08:14  <Webster> planetmaker: 31
13:20:43  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 256: Change: locomotive length code on refit for industri... <>
13:32:03  <Ammler> since sfx 0.2.2 is released
13:32:13  <Ammler> something to do for gfx 0.2.2?
13:33:05  <Ammler> (I mean something I can help?)
14:11:57  <planetmaker> hello Ammler :-)
14:12:05  <planetmaker> Few things come to my mind:
14:12:40  <planetmaker> - Some RV have gotten updated sprites
14:12:59  <planetmaker> - The OpenGFX readme in the wiki could need updating to match the current readme of OpenGFX
14:13:14  <planetmaker> - Maybe you could fiddle with the spice-blue eyes
14:13:14  <Ammler> the wiki is a big mess
14:13:47  <Ammler> I have no idea, where to start there...
14:14:28  <planetmaker> Personally I'd do nearly a copy&paste and then beautify it by applying a bit of wiki style. Keeping the nice menu
14:15:08  <Ammler> well, the menu links 90% to obsolete depreciated other pages
14:15:32  <Ammler> the only valid links are forum and devzone
14:16:19  <planetmaker> it's also the content of that page, is it not?
14:16:40  <planetmaker> hm, it's not
14:17:33  <planetmaker> well. Maybe links directly to the tracker, directly to the sprite list (does it need updating?), forum threads and devzone
14:17:38  <planetmaker> download link
14:17:57  <planetmaker> I like to have that image (or another nice one) on that page .-)
14:18:16  <Ammler> yes, agreed :-)
14:19:23  <Ammler> as said, I would like to move OpenGFX_Readme to OpenGFX and OpenGFX_Readme a description how to get the readme...
14:20:41  <planetmaker> well... but from the repository we cannot maintain a nice web page on the wiki
14:20:56  <Ammler> yeah, we keep the wiki
14:21:07  <planetmaker> readme.html?
14:21:14  <Ammler> why?
14:21:31  <planetmaker> .txt is plain text. Without images and stuff
14:21:53  <Ammler> you like to use the wiki as readme to the bundle?
14:22:00  <planetmaker> But the bundles always need to come with a readme IMHO. Not with a plain link to a web-based readme.
14:22:27  <Ammler> yes
14:22:41  <Ammler> OpenGFX_Readme links to the readme.txt
14:22:44  <planetmaker> I don't like both: a) having the wiki point to a plain text readme b) having the shipped readme point (only) to the wiki readme
14:23:02  <Ammler> what is bad about a?
14:23:02  <planetmaker> as the readme.txt is only plain text. Boring
14:23:13  <Ammler> yes, that we have OpenGFX wiki for
14:23:13  <planetmaker> The wiki page as it's now looks much nicer
14:23:23  <planetmaker> You mean on the devzone?
14:23:27  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 257: Add: psd for tram locomotives <>
14:23:27  <Ammler> no
14:23:36  <planetmaker> I don't understand
14:24:04  <Ammler> we keep as official homepage
14:24:18  <planetmaker> Ok. And?
14:24:27  <Ammler> but the official readme should become readme.txt
14:24:52  <planetmaker> So... what purpose does the "official" homepage serve?
14:25:16  <Ammler> like it is now,  but without need to sync readme...
14:25:40  <planetmaker> Like now it's horribly outdated and partially wrong
14:25:41  <Ammler> like a homepage :-)
14:25:54  <Ammler> yes, data, which are outdated get removed
14:26:00  <Ammler> not replaced
14:26:30  <planetmaker> That's why I said: Copying the readme there makes sense. And possibly - as you proposed - add a link to the official readme.
14:26:45  <planetmaker> Stripping the official homepage of all content is not sensible.
14:26:51  <planetmaker> It needs updating. Not removing.
14:27:08  <planetmaker> And removing all outdated = removing 90%.
14:27:43  <Ammler> yes, that is how a homepage should be
14:28:00  <Ammler> just a few infos, compact but everything needed.
14:28:13  <Ammler> but links to details
14:28:18  <planetmaker> The readme is "everything needed and compact"
14:28:24  <Ammler> like the official readme
14:28:57  <Ammler> well, you have do decide what you want...
14:29:03  <Ammler> where is the official readme?
14:29:28  <Ammler> as we started, it was the wiki and we copied the content to the bundle
14:29:39  <Ammler> now, I thought, it is the readme.txt
14:29:48  <planetmaker> yes. That's it.
14:29:55  <Ammler> but the description in the obg still tells the wiki
14:30:13  <planetmaker> But it doesn't mean that we can have the readme as of releases there, too
14:31:00  <planetmaker> ah. Then that description... hm... should now not change as it was just translated ;-)
14:31:34  <Ammler> _I_ told you to think about as Rubidium made the thread :-P
14:31:50  <Ammler> but that doesn't matter
14:32:05  <Ammler> we can still link from OpenGFX_Readme to readme.txt
14:32:07  <planetmaker> :-) Well, sorry.
14:32:13  <Ammler> that is my "workaround"
14:32:25  <Ammler> and use wiki OpenGFX as homepage
14:33:34  <Rubidium> Ammler: I did what?
14:33:55  <Ammler> also we shouldn't explain things in the OpenGFX readme, which are already in openttd reamde
14:34:23  <Ammler> we should rather expect or tell the people, they read it self there
14:34:25  <Rubidium> Ammler: do you really expect people to read OpenTTD's readme? :(
14:34:44  <Ammler> Rubidium: as much as they read OpenGFX readme :-)
14:35:07  <Rubidium> openttd's readme refers to opengfx/opensfx/openmsx's readme
14:35:29  <Ammler> I think, the data storage part is redundant
14:36:59  <Rubidium> yeah, but redundancy isn't that bad in this case
14:37:15  <Rubidium> it's only 5 lines or so
14:37:20  *** DJNekkid has quit IRC
14:37:50  <Rubidium> <- when upgrading that in bananas it might not be true anymore
14:38:21  <planetmaker> <Ammler> also we shouldn't explain things in the OpenGFX readme, which are already in openttd reamde <-- Ammler, we shouldn't be too condescending
14:38:48  <planetmaker> It's no big deal to have the readme.txt placed there nearly as-is in the wiki and link to the official readme.txt
14:39:33  <planetmaker> Pointing out to people constantly "you find A here, B there, C another place" is... just unnecessary work, if we can link to the answers of FAQ straight away
14:39:49  <Rubidium> I'd even link to from the wiki :)
14:40:03  <planetmaker> :-)
14:40:11  <planetmaker> yes, something like that
14:41:37  <planetmaker> after all we want a good user experience and not an exercise in "learn the project's subtle sub-project structures and their respective responsibilities"
14:41:59  <planetmaker> (if you consider OpenTTD the project and all related content sub-projects)
14:44:32  <Rubidium> yeah
14:47:50  <Rubidium> does it make sense to implement some three-monthly release cycle for open..x? Say roughly the 1 week before the start of a new quarter? That way we could somewhat sync releases as I kinda like the beta/RC cycle of 1.0.0
14:48:35  <Rubidium> although for the sound/music related stuff it doesn't matter as much as for the graphics (new sprites are more or less already in the queue)
14:49:36  <Ammler> don't we do that already?
14:49:53  <Ammler> I mean, release 0.2.2 is ruled by openttd 1.0.0 release :-)
14:50:30  <Ammler> I am sure, 1.0.1 will "push" another opengfx release :-)
14:50:39  <Rubidium> true, but a regular release schedule is beneficial for downstream packagers
14:51:02  <Ammler> well, we could make our roadmap like that...
14:51:09  <Rubidium> Ammler: unlikely that new sprites get added to 1.0.1 :)
14:51:41  <Ammler> oh, you mean new sprites like new Action5 features?
14:51:51  <Rubidium> yes
14:52:15  <Rubidium> stuff like the "shade" sprite
14:52:34  <Rubidium> although in this case I expect a sprite for NewGRF debug purposes
14:52:38  *** DJNekkid has joined #openttdcoop.devzone
14:54:29  <Ammler> well, I would release such set with trunk
14:54:31  <Webster> Latest update from devactivity: OpenGFX - Feature #840: Improved signal sprites <> || OpenGFX - Feature #771 (Closed): bundle md5 for source releases and check for them. <>
14:54:33  <Ammler> and not with openttd release
14:55:59  <Ammler> else we need to start uploading nightlies to bananas
14:57:17  <Ammler> a new feature is always worth a gfx release...
14:57:36  <planetmaker> Hm, I think the addition of completely new sprites to OpenTTD should trigger a bug fix release of OpenTTD, regardless when
14:57:43  <Ammler> as soon the release is capable to ;-)
14:57:57  <Rubidium> planetmaker: why?
14:58:21  <Ammler> planetmaker: you meant opengfx?
14:58:29  <planetmaker> well... for the sake of those people who play nightlies :-) Then they can get it from Bananas. Yes, I mean OpenGFX
14:59:05  <planetmaker> Or we do start uploading non-release versions to BaNaNas.
14:59:43  <Ammler> or split the base sets with min/max versions
14:59:48  <Ammler> kinda testing releases
15:00:03  <planetmaker> I mean... there are hundreds of downloads for nightlies. Isn't it worth to supply a working base set also via bananas?
15:00:37  <Rubidium> true, actually... I think a few hours ago the 1 million marker for stable OpenTTD downloads has passed
15:00:49  <Ammler> but I still don't see, why a 1.0.0 user shouldn't benefit of better sprite updates.
15:01:12  <planetmaker> Otherwise... and unharmed by those out-of-order bug fix releases, I have no principal problem with a semi-regular release cycle.
15:01:32  <Rubidium> but maybe we at OpenTTD could try to keep sprite additions to 4 points in the year (two weeks before a new quarter or so)
15:01:36  <Ammler> sadly those linux distros don't have stats about package usage
15:01:47  <Rubidium> Ammler: Debian somewhat has
15:02:11  <Ammler> too many mirrors in use
15:02:18  <Rubidium> Ammler:
15:02:24  <Webster> Title: Debian Developer's Packages Overview -- Debian Quality Assurance (at
15:02:35  <planetmaker> Rubidium, I don't think that's particularily needed... and puts a mostly unnecessary constraint on it.
15:03:46  <Ammler> I think, we can plan to have a release shortly before openttd releases
15:03:48  <Rubidium> planetmaker: true, but that more or less means that you need to keep opengfx in 'releaseable' state at all times to quickly release a version with an added sprite or start with "stable branches"
15:03:50  <planetmaker> Personally I'd say it's just fine to talk to each other about that so that the release can possibly be prepared timely. Bug fix releases for OpenGFX are IMHO "easy"
15:04:03  <Ammler> and make bug fix release on need
15:04:04  <planetmaker> Hm, yes, true
15:04:32  <planetmaker> But then... I hope to not break OpenGFX with anything really :-)
15:04:42  <Ammler> hmm, how can we?
15:04:51  <Ammler> it isn't like a newgrf,
15:04:58  <planetmaker> Well, it's mostly a constraint on your part, I certainly can live with that solution, Rubidium :-)
15:05:21  <Ammler> we can only add features you allow us to
15:05:59  <Rubidium> that's true too, although you're still busy with cleaning up the repository and such
15:06:10  <planetmaker> hehe, very much so.
15:06:17  <planetmaker> It's still in large parts a big mess
15:06:35  <planetmaker> I guess like OpenTTD 3 years ago or so.
15:06:41  <planetmaker> maybe 4
15:06:57  <Rubidium> you mean before the map accessors
15:07:25  <planetmaker> possibly yes. And with many 1:1 copies of structures and stuff
15:07:39  <planetmaker> maybe OpenDune is the better comparison ;-)
15:07:50  <Rubidium> _m[10].m1 = _m[10].m1 & 0xF | (n << 4);
15:08:01  <planetmaker> urgs
15:08:12  <Ammler> and we could still add a branch "work" or so, if we add some experimental stuff like you do in trunk after branching
15:08:18  <Rubidium> hmm, might need a bit more parens :)
15:09:06  <planetmaker> Rubidium, something we can most certainly agree on now in any case is: there should and will be a new base set release for the major version change of OpenTTD. It makes sense
15:09:35  <planetmaker> I'm not sure there needs to be a base set release for every minor version change.
15:09:39  <Webster> Latest update from devactivity: OpenGFX - Feature #662 (Assigned): Rework trains <>
15:10:07  <planetmaker> Sure in the sense of whether it's (always) sufficient change to justify a release
15:10:08  <Ammler> well, from view of package maintainer, it would be nice to have a very stable opengfx ready when openttd does release something
15:10:24  <Ammler> so the packager doesn't need to work for opengfx only
15:11:20  <Ammler> so in my eyes, it wouldn't be the worst, if we release around 2 weeks earlier then openttd
15:11:34  <planetmaker> Ammler, yes, that's not the worst, I agree.
15:11:42  <planetmaker> It might even be desirable.
15:11:42  *** welshdragon has joined #openttdcoop.devzone
15:11:46  <Ammler> so we could flip in a bugfix release before openttd release
15:12:09  *** welshdragon has quit IRC
15:12:52  <Ammler> s/before/with/
15:13:21  <Rubidium> some sort of RC and if nothing pops up you just leave it at that :)
15:13:34  <Ammler> yes :-)
15:13:36  <planetmaker> :-)
15:14:05  <planetmaker> Well. That'd mean that we do no changes in the time between. At least not to trunk.
15:14:06  <Ammler> that is why it wouldn't hurt to release 0.2.2 now :-P
15:14:19  <planetmaker> Ammler, yes, it wouldn't. And I think I might just do that.
15:14:19  <Rubidium> like the 1.0.0-RC3 (+ one patch) = 1.0.0, 1.0.1 has already 10 or so patches
15:14:41  <Rubidium> should I do some small sanity tests first?
15:14:59  <planetmaker> Rubidium, why not in 1.0.0? As they're too major to be added to the 1.0.0 RC?
15:15:31  <planetmaker> How is it that you decide something to go in the next release or the next bug fix release?
15:15:34  <Rubidium> planetmaker: because 0.7.4 taught me not to do that again
15:16:04  <planetmaker> hm, please remind me, what was the issue?
15:16:12  <Rubidium> planetmaker: can crash 1.0.0 under normal circumstances -> 1.0.0, can't -> 1.0.1
15:16:21  <Ammler> Rubidium: I also think the RC releases for bugfix releases a bit overrated
15:16:44  <Rubidium> planetmaker: NewGRF cargoes having price 0 in new games
15:17:02  <planetmaker> ah... which crashed. Right
15:17:04  <Ammler> as nobody does use RCs then anymore
15:17:09  <Rubidium> Ammler: no, see 0.7.4 why we should do them and why we shouldn't try to fix stuff in between
15:17:29  <Ammler> but you have same work for RC than bugfix release
15:17:38  <Ammler> so you could just release another bugfix release
15:17:53  <planetmaker> Ammler, the popularity / spread is far different
15:18:00  <Rubidium> 2-3 thousand downloads per 0.7 RC (2-3% of non-RC)
15:18:17  <Rubidium> but they have more than once caught major issues
15:18:26  <Ammler> yes, that is RC of 0.7
15:18:33  <Ammler> but how is it with RC of 0.7.5?
15:18:41  <Rubidium> Ammler: 2766
15:18:51  <Ammler> that is like none :-)
15:19:06  <planetmaker> twice nightly.
15:19:53  <planetmaker> well... I wonder whether OpenGFX needs that, RCs. And if so, how to announce them and get them tested
15:19:55  <Rubidium> I'm going to keep the RCs, but I'm going to change the release cycle slighty; one RC, 2 weeks before the release, no changes after the RC except regressions
15:20:43  <Rubidium> planetmaker: make clean/mrproper on OpenGFX force a full build (kinda very pointless)
15:20:51  <planetmaker> I also wonder if it's worth to make branches for OpenGFX, bug fix and major.
15:20:52  <Ammler> planetmaker: the issue is, if you release a RC and it is fine
15:21:06  <Ammler> so how do you change the md5sum?
15:21:16  <planetmaker> Ammler, by the new tag
15:21:40  <planetmaker> which changes md5sum of extra and obg
15:21:40  <Rubidium> planetmaker: make clean/mrproper leaves sprites/*.bak, docs/*.txt (CLEAN_ADD = docs/changelog.txt docs/license.txt docs/readme.txt sprites/*.bak ?)
15:22:30  <planetmaker> yes, that should work
15:22:32  <Rubidium> Ammler: releasing OpenSFX 0.2.2 is more (manual) work that releasing a RC/beta of OpenTTD
15:22:55  <Rubidium> (the manual building, copying, getting the md5sum etc)
15:23:10  <planetmaker> hm... make_release again? :-)
15:24:14  <planetmaker> Rubidium, do you have any idea *why* clean and mrproper force a dep check (and build?)
15:24:35  <planetmaker> besides: they only force it when the version changed.
15:25:59  <Ammler> planetmaker: you should also add files to mrproper, you remove from .hgignore like REV
15:26:31  <planetmaker> mrproper should clean *.REV
15:26:40  <Ammler> *.REV != REV
15:26:49  <planetmaker> I know
15:26:49  <Ammler> he you could change it *REV
15:27:03  <Ammler> you used REV before, afaik
15:27:21  <Ammler> or was that a file of me?
15:28:32  <planetmaker> I used REV before
15:29:18  <Ammler> everthing, which Makefile does generate, Makefile should also clean...
15:29:34  <Ammler> so you make and generate a REV and update repo
15:29:45  <Ammler> now REV isn't part of make anymore
15:29:52  <Rubidium> planetmaker: <- fixes it; cause is Makefile.dep depending on opengfx.obg which needs to compile the rest to build; Makefile.dep should just depend on the .pnfo files
15:30:37  <planetmaker> ah, right. Thx.
15:30:58  <planetmaker> And I broke my head already two hours about that... :S
15:31:13  <Rubidium> make -d my friend :)
15:31:30  <planetmaker> :-)
15:32:59  <planetmaker> have you pushed that (and the above CLEAN_ADD fix), Rubidium ? Or shall I now
15:33:08  <Rubidium> I've not even committed it
15:33:19  <Ammler> <-- why is there no opengfx?
15:33:30  <planetmaker> ok, then I'll apply those changes
15:33:42  <Rubidium> Ammler: because your browser's search does not work
15:33:45  <Ammler> ah, nvm.
15:33:59  <Ammler> there is
15:35:55  <Ammler> is it really not possible to make a shared dir between 2 unix users (rw)
15:36:05  <Ammler> while the umask is 022
15:36:37  <Ammler> maybe I do it with ssh
15:40:02  <planetmaker> hm, I guess the REV_FILENAME should only be cleaned by mrproper
15:40:06  <planetmaker> or should it?
15:40:41  <planetmaker> hm... it's a dependency thing... hm.
15:40:44  <Webster> Latest update from devactivity: OpenGFX - Revision 397: Fix: [Makefile] Don't build when calling clean and mrproper but clean mor... <> || Example NewGRF Project - Feature #866 (Assigned): Clean the txt files which are generated from pt... <> || HEQS "Heavy Equipment" Set - Revision 259: Add: psd for tram wagons <> || HEQS "Heavy Equipment" Set - Revision 260: Add: pcx files for trams <> || HEQS "Heavy Equipment" Set - Revision 258: Change: test locomotive and wagons for industrial tram <>
15:40:53  <planetmaker> same as MAKEFILE.DEP
15:41:11  <planetmaker> Rubidium, what do you say: clean dependencies on clean or only mrproper?
15:44:12  *** OwenS has joined #openttdcoop.devzone
15:44:29  <Ammler> mrproper shouldn't have "functional" effect
15:44:47  <Rubidium> planetmaker: technically with clean
15:45:20  <Rubidium> as it doesn't record configuration
15:46:45  <planetmaker> ok, then I leave it.
15:49:54  <Rubidium>
15:51:45  <Rubidium> the rest seems fine (compile wise)
15:52:36  <planetmaker> ah, ok
15:53:20  <Rubidium> regarding the readme: in 1.0.0 you're probably not going to get the error anymore
15:54:04  <OwenS> Why does nforenum call tiself renum anyway? :-S
15:54:23  <Rubidium> OwenS: because it started out as a simple script (
15:54:28  <OwenS> Aah
15:54:43  <Rubidium> more readme: recent nightly <- any binary nightly would suffice now :)
15:54:59  <planetmaker> hehe :-)
15:55:20  <Ammler> Rubidium: which readme? :-P
15:55:39  <Rubidium> readme: 4 Reporting bugs and Contributing <- if you prefer the tracker, then list that first
15:55:58  <Rubidium> Ammler: the one in the binary package generated from HG
15:56:04  <Webster> Latest update from devactivity: Example NewGRF Project - Revision 80: Fix (r77): Don't rebuild when calling clean or mrproper. On... <>
15:56:44  <Rubidium> more: insalled <- installed
15:57:26  <Rubidium> moar: 5.1 Note for package maintainers: <- mention make check
15:57:38  <planetmaker> Rubidium, the error is gone / not there anymore?
15:57:54  <planetmaker> Hm... should we care about 0.7.x users?
15:58:23  <Rubidium> planetmaker: we package no_sound in OpenTTD's package, so only opengfx is needed to start OpenTTD
15:59:13  <planetmaker> he... seems like I only forgot to remove the heading there. The section doesn't exist.
16:00:20  <Rubidium> the rest seems okay (this was only a quick scan though)
16:03:34  <Ammler> Rubidium: we=debian
16:03:51  <Ammler> or is nosound now in the openttd source?
16:04:18  <planetmaker> yes
16:05:21  <Rubidium> Ammler: we as in OpenTTD
16:07:21  *** Seberoth has joined #openttdcoop.devzone
16:07:29  <Ammler> hmm, then I can remove that package :-)
16:11:18  <Webster> Latest update from devactivity: Example NewGRF Project - Revision 81: Change: Make Debian and Fedora users happy (Rubidium) <> || OpenGFX - Revision 398: Change: Make Debian and Fedora users happy (Rubidium) <>
16:15:05  <Rubidium> joepie!
16:17:04  <Ammler> did ever someone try to build OpenGFX on windows?
16:17:40  <Ammler> since Foobar is off, maybe not :-)
16:19:33  <planetmaker> hm, maybe I should install again parallels and then a windoze...
16:20:15  <Rubidium> those are the lesser evils of building OpenGFX on Windos (or Faildos?)
16:21:03  <planetmaker> <Rubidium> joepie! <-- that reads certainly like Dutch ;-) (translated into German as Yippieh! ;-) )
16:27:00  <Webster> Latest update from devactivity: OpenGFX - Revision 399: Doc: Update readme a bit <>
16:29:34  <Yexo> Ammler: yes, I did
16:29:36  <Yexo> it works fine
16:30:03  <planetmaker> Good to know :-)
16:30:59  <Ammler> Yexo: mingw/msys or cygwin?
16:31:06  <Yexo> cygwin
16:31:13  <Yexo> I can try mingw/msys too if you want
16:31:40  <planetmaker> would be interesting to know
16:31:55  <planetmaker> if it's not too much of a hassle.
16:31:58  <Ammler> specially tip
16:32:09  <Ammler> with all the new Makefile features
16:37:05  <Yexo> I don't have hg installed in msys, I get this output:
16:37:48  <Yexo> is mercurial needed to build opengfx?
16:38:00  <Ammler> yes, you could build source tarball
16:38:02  <planetmaker> Yexo, from a checkout: yes. Otherwise you'll need a source release
16:38:05  <Ammler> which then doesn't neet it
16:38:15  <Ammler> make bundle_src
16:38:16  <Yexo> ok
16:38:27  <Ammler> (in cygwin)
16:38:59  <Yexo> cygwin builds it without problems
16:39:09  <Ammler> yes, there you could build the source tar
16:39:23  <planetmaker> make bundle_src should give you a .tar.gz
16:39:44  <Yexo> working on that, but every make comment is very slow
16:40:07  <Yexo> "rm *; hg revert --all" is way faster then "make mrproper" for example
16:40:13  <Yexo> 2 seconds vs 30seconds+
16:40:58  <planetmaker> hm... :S
16:41:20  <Yexo> make bundle_src takes over a minute
16:41:22  <Yexo> should've timed it
16:41:37  <planetmaker> I guess at some stage I should remove some vars.
16:41:50  <planetmaker> Yexo, bundle_src needs a full build and then creation of the source
16:42:11  <Yexo> planetmaker: I had just done "make" before
16:42:13  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 262: Change: offsets for tramcars <> || HEQS "Heavy Equipment" Set - Revision 261: Change: tram coal car all angles <>
16:42:14  <Yexo> so the build was already done
16:42:14  <planetmaker> (the full build is required in order to produce the md5 file which contains the check sums shipped with the source)
16:42:36  <Yexo> that also took over a minute
16:42:47  <planetmaker> wow...
16:43:54  <planetmaker> I guess windows is slower with these things...
16:44:30  <planetmaker> (not that OpenGFX make is particularily lightening fast)
16:44:38  <planetmaker> real    0m53.827s
16:44:38  <planetmaker> user    0m29.726s
16:44:38  <planetmaker> sys     0m14.917s
16:44:55  <Yexo> what did you do to get that timing?
16:44:56  <planetmaker> ^ for a make bundle_src after I ran make mrproper before
16:45:00  <Yexo> ah, ok
16:45:26  <planetmaker> on a 2.6GHz P4
16:46:21  <Yexo> I'm running it now
16:47:06  <OwenS> planetmaker: 2.6GHz P4? Wow, people are still running those? :-P
16:47:13  <planetmaker> yes...
16:48:16  <Ammler> pm, one core?
16:49:28  <planetmaker> yes
16:50:53  <Yexo> real    5m11.807s
16:50:53  <Yexo> user    6m17.272s
16:50:53  <Yexo> sys     3m45.032s
16:51:07  <Yexo> core 2 duo @2.0ghz
16:52:17  <Yexo> when running make in msys it stops after: [NFORENUM] ogfx1_base.nfo
16:52:17  <Yexo> NFORenum v3.4.6 r2309 - Copyright 2004-2009 Dale McCoy.
16:52:17  <Yexo> Processing from standard input.
17:00:18  <Ammler> looks like piping doesn't work?
17:01:33  <Yexo> no, renum just ignores all command line arguments in mingw
17:01:53  <Yexo> I remember that I had that problem before (also with other programs), but I don't think I ever found a fix
17:02:21  <Ammler> but it worked before
17:02:35  <Yexo> not for me
17:02:35  <Ammler> foobar didn't cygwin
17:02:39  <Ammler> use*
17:02:50  <Yexo> it's probably a problem with my installation then
17:02:56  <Ammler> also didn't DJNekkid
17:03:39  <Ammler> but he uses linux for building now, afaik
17:04:26  <DJNekkid> i what?
17:04:27  <DJNekkid> yes
17:04:28  <DJNekkid> :)
17:04:53  <Ammler> DJNekkid: still mingw/msys installed?
17:05:03  <Ammler> could you try to build opengfx?
17:05:22  <DJNekkid> i never installed them on this computer iirc
17:05:26  <DJNekkid> i had it on my old one
17:05:37  <DJNekkid> but i got my new laptop and server at the same time
17:06:00  <DJNekkid> hmm
17:06:05  <DJNekkid> seems like i do have them installed
17:06:56  <DJNekkid> but i dont seem to have the paths set up etc
17:08:01  <DJNekkid> cloneing opengfx now
17:10:24  <DJNekkid> but i get some errors on windows
17:10:45  <DJNekkid> (useing msys commandline, not cmd)
17:11:19  <DJNekkid> running in my linux box took like 5sec
17:11:46  <DJNekkid> msys gave LOTS of "Grep"-errors
17:12:14  <Ammler> DJNekkid: nevermind, as you didn't use the system to build before
17:12:21  <DJNekkid> and then ultimately:    make: *** no rule to make target 'ogfx1_base.nfo"
17:14:42  <DJNekkid> i've added the path, i'll reboot and try... brb
17:18:32  <planetmaker> Yexo, interesting. A year ago or so I still had a MinGW environment and I didn't have trouble with calling nforenum. I guess I shall check again. The system is still on my backup disc
17:22:50  <DJNekkid> same error as ealier
17:22:57  <DJNekkid> no grep errors this time
17:23:25  <DJNekkid> but still the "make: *** no rule to make target 'ogfx1_base.pnfo', needed by 'makefile.dep'. Stop.
17:23:35  <Yexo> try make clean, then make again
17:24:13  <DJNekkid> *on it*
17:24:21  <DJNekkid> same error on make clean
17:25:22  <planetmaker> hm... makefile.dep depends on ogfx1_base.pnfo, that's intended
17:25:25  <DJNekkid> same on make remake
17:25:34  <planetmaker> and it *should* find it.
17:27:29  <DJNekkid> but it dont
17:27:43  <Ammler> DJNekkid: hg up -r200 or so
17:29:51  <DJNekkid> that one worked
17:30:46  <planetmaker> you can build r200 but not tip? Hm..
17:32:00  <DJNekkid> yes
17:32:04  <DJNekkid> with windows
17:32:10  <DJNekkid> linux works on tip
17:33:52  <Ammler> I see no difference...
17:34:23  <Ammler> hmm, DJNekkid, could you try r396?
17:34:29  <planetmaker> I guess I shall test at some stage....
17:35:21  <DJNekkid> sure i can
17:36:28  <Ammler> [ `which nforenum 2>/dev/null` ] && echo "nforenum" || echo "renum" <-- run that in your shell
17:36:45  <DJNekkid> in windows?
17:36:58  <Ammler> yes, where else?
17:37:03  <Ammler> :-)
17:40:37  <DJNekkid> "the system cant find the path"
17:41:28  <DJNekkid>
17:42:06  <Rubidium> oh, that's just grep brokeness
17:42:15  <Rubidium> or oldness
17:44:40  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 263: Change: locomotive sprite for tram, offsets <>
17:46:03  <Ammler> indeed, might be possible r200 didn't use grep
17:46:40  <Ammler> how did you setup $PATH?
17:47:13  <Ammler>
17:48:34  <planetmaker> grep might need separate installation with mingw
17:49:47  <planetmaker> at least older Makefiles didn't use grep -o
17:49:54  <planetmaker> It's an option I also only recently found ;-)
17:51:50  <planetmaker> DJNekkid, can you tell me the output of "grep --version" ?
17:52:33  <DJNekkid> 2.4.2
17:52:43  <planetmaker> thanks
17:53:17  <DJNekkid> too old or something?
17:53:20  <Rubidium> mingw crap is at least 5 years old anyway
17:53:34  <planetmaker> well, I do have 2.5.2 here
17:53:42  <planetmaker> and the -o option available
17:54:25  <OwenS> 2.5.4 here. DJNekkid, what copyright date does Grep say?
17:54:51  *** frosch123 has joined #openttdcoop.devzone
17:55:19  <Ammler> planetmaker: I build opengfx on suse 9
17:55:29  <planetmaker> :-)
17:55:31  <Ammler> around 5 years old?
17:55:35  <DJNekkid>
17:55:37  <Ammler> well
17:55:39  <planetmaker> puh... Dunno, Ammler
17:55:41  <Ammler> not tip
17:55:42  <DJNekkid> updated that screenshot
17:56:06  <Rubidium> oh, only 10 years old :)
17:56:32  <planetmaker> lol
17:56:59  <planetmaker> DJNekkid, what does the message below the line starting with [ `witch nforenum 2>/dev/null' ] mean?
17:57:12  <OwenS> witch nforenum? You gonna curse it?
17:57:21  <DJNekkid> planetmaker: i have absolutely no idea
17:57:25  <planetmaker> *which
17:57:30  <OwenS> :-P
17:57:41  <planetmaker> actually... the command there was "witch" :-P
17:57:46  <Ammler> no, can't build opengfx on suse9, renum fails there
17:57:58  <Ammler> would need renum working with gcc33
17:58:17  <planetmaker> that *should* work afaik
17:58:55  <OwenS> gcc33? suse 9? Whats with the old stuff? :p
17:59:42  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 264: Change: tweak tram wagon interior graphics; fix some... <>
18:00:02  <Ammler> OwenS: that is officially supported until next october or around
18:00:58  <Ammler> everything else does build on all "better" rpm distros
18:01:27  <Ammler> (Fedora/CentOS/RHEL, Mandriva & Suse)
18:01:39  <OwenS> Meh. Im a deb distro guy :p
18:01:46  <OwenS> Well, deb & pkg(7)
18:02:15  <Ammler> what gcc does oldest supported deb distro use?
18:02:43  <planetmaker> sentence that parse not well :-P
18:02:52  * OwenS queries Debian & Ubuntus homepages
18:03:07  * planetmaker stops nitpicking now
18:03:45  <Ammler> suse is known to have a quite big support range, maybe that is a bad policy ;-)
18:05:25  <OwenS> Debian Etch is  already out of support? :O
18:05:28  <OwenS> They move fast these days
18:05:48  <OwenS> Ubunty 6.06 LTS is the oldest, if you count a server-only distro
18:06:34  <Rubidium> OwenS: Debian's policy is to support for one year after the next release
18:06:52  <OwenS> In that case Etch EOLs Jan 30 2011
18:07:05  <OwenS> I just can't see any Etch packages in their security advisories
18:07:28  <Rubidium> OwenS: huh? Lenny was released 14-02-2010
18:07:49  <Rubidium> uhm, 2009*
18:08:26  <Rubidium> 30-01-2010 was just a "service pack" of Lenny
18:08:33  <OwenS> Gah woops, i'm obviously looking in the wrong place as I read the latest servic pack date :p
18:08:50  <Ammler> planetmaker: you can quite easy setup a chroot with every rpm distro you like on our server
18:08:53  <OwenS> Problem with Debian: Poorly laid out website :p
18:09:12  <OwenS> Ammler: Though doing it  with debian derivatives is easier
18:09:21  <Rubidium> OwenS: or bad reading!
18:10:19  <Ammler> Rubidium: why is there no dsc file in openttd debian build branch?
18:10:52  <Rubidium> although you'll always have someone who can't find what he needs immediately, no matter what the design is
18:11:16  <Ammler> hmm, could be the same as control
18:11:28  <Rubidium> Ammler: because that implies a source tarball and a debian tarball/diff
18:12:14  <Ammler> you can't build debian directly from the release sources?
18:12:39  <Rubidium> and knowing the checksums/filesize for those files
18:12:48  <Rubidium> Ammler: check the wiki
18:12:54  <Ammler> oh well
18:13:09  <Ammler> was just wondering, if I can run debian too, not really necessary...
18:13:27  <Rubidium> you probably can, in a chroot ofcourse
18:13:42  <Ammler> yes, but it ask for a dsc file :-)
18:13:49  <Ammler> like spec for rpm
18:13:51  <Rubidium> we use chroots (in a vbox) for Debian/Ubuntu
18:14:06  <Rubidium> Ammler: what asks for that?
18:14:23  <Ammler> the build system to create a package or in my case the chroot
18:14:36  <Ammler> I use "dummy" specs to build a chroot
18:14:59  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 265: Add: psd for tram wagons 1; rename previous file to ... <>
18:15:20  <Rubidium> Ammler: you'll first have to run dpkg-buildpackage to create a source package which your tool can then compile
18:15:49  <Rubidium> it's usually easier to just to cd $openttd && ln -s os/debian debian && debian/rules binary
18:17:00  <Rubidium> anyhow, that's what OpenTTD's CF uses
18:17:50  <Rubidium> you could use debuild, but then you'd need to figure out what to pass exactly because it doesn't quite like the default naming of the directories
18:18:03  <Ammler> ah, I see
18:18:15  <Ammler> os/debian would be packages as debina.tar.gz
18:18:30  <Rubidium> yeah
18:18:40  <Ammler> and then there is a <pakcage>.dsc
18:19:01  <Rubidium> well, you have to construct that
18:19:20  <Rubidium> cause the three statements I just gave you only build the binary
18:19:38  <Ammler> does the makefile do that?
18:20:10  <Rubidium> given that debian/rules is a makefile, yes
18:24:06  <Rubidium> but for what do you want to make debian packages?
18:24:21  <Ammler> not debian packages
18:24:29  <Ammler> a debian chroot
18:24:37  <Ammler> but not really :-)
18:40:15  *** frosch123 has quit IRC
18:45:21  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 268: Change:tweaks to industrial tram <> || HEQS "Heavy Equipment" Set - Revision 267: Change: make being weird after a file rename - shuff... <> || HEQS "Heavy Equipment" Set - Revision 266: Change: renamed pcx, resized some wagons <>
19:01:20  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 269: Change:tweaks to industrial tram hp etc <>
19:28:51  <Ammler> tt-forums often crashes my whole browser lately...
19:30:30  <OwenS> Ammler: get a less sucky browser
19:48:05  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 270: Change: removed unneeded date check for arv building... <>
20:04:12  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 271: Change: improved texts for tram 1 <> || OpenMSX - Revision 39: Feature: 'Train filled with cash' by imuh3 <> || OpenMSX - Revision 38: Change: Reorder songs a bit <> || OpenMSX - Revision 37: Change: Replace 'Rubens Random Kingodom' by 'Run For Your Life' (both Tist... <> || OpenMSX - Revision 36: Change: Replace 'Simple ride' by 'Ultimate run' (both Tistou Blomberg) <> || OpenMSX - Revision 35: Change: Replace 'Wandering Dark Castle' by 'Coconut Run 2' (both Tistou Bl... <> || OpenMSX - Revision 34: Feature: Add -lucas-' title theme <> || OpenMSX - Revision 33: Change: rename 'Smooth Groove's file matching the song name <>
20:08:31  <Ammler> I guess, it is that midi plugin
20:09:04  <planetmaker> hm?
20:19:30  <Webster> Latest update from devactivity: OpenMSX - Revision 43: Update: Changelog <> || OpenMSX - Revision 42: Fix: Readme wouldn't show the repo's title anymore <> || HEQS "Heavy Equipment" Set - Revision 272: Feature: Kreuzberg Industrial Tram <> || OpenMSX - Revision 41: Fix: Installing a tar won't work, we need to install the dir directly <> || OpenMSX - Revision 40: Fix: Install in the gm dir, not in the data dir <>
20:36:08  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 273: Change: Kreuzberg tram loco better at 3/8 length <>
21:00:47  *** Seberoth has quit IRC
21:22:29  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 275: Change: moved tram wagons pcx to a directory <> || HEQS "Heavy Equipment" Set - Revision 274: Change: support for Henningsdorf tram locomotive <> || #openttdcoop - Revision 46: [chroots] Add: chroot to build grfs (dummy rpm spec) <> || #openttdcoop - Revision 45: [OpenTTD] Change: file transfer via ssh <>
21:24:37  *** frosch123 has joined #openttdcoop.devzone
21:54:37  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 279: Change: tweaked sprites for tram wagon 2 <> || HEQS "Heavy Equipment" Set - Revision 278: Change: bigger sprites for tram wagon 2 <> || HEQS "Heavy Equipment" Set - Revision 277: Change: tram wagon 2 features correct refit capacities <> || HEQS "Heavy Equipment" Set - Revision 276: Add: pcx for tram wagons 2 <>
22:15:30  *** frosch123 has quit IRC
22:19:42  <Ammler> planetmaker: don't you have instrument drops with MSX?
22:20:26  <planetmaker> well... hard to tell :-)
22:20:35  <Ammler> afaik, it is even worse with debian...
22:20:43  <planetmaker> But I run Quicktime
22:21:11  <Ammler> so no "real" debug output?
22:22:25  <planetmaker> I didn't yet check the console
22:24:31  <planetmaker> but the console is clean in that respect
22:26:08  <planetmaker> so... it *should* all work to my knowledge.
22:26:19  <planetmaker> But I didn't test on my SuSE yet
23:04:02  *** ODM has quit IRC

Powered by YARRSTE version: svn-trunk