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: http://dev.openttdcoop.org/projects/firs/repository/show/sprites/nfo 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 broken...so... 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/244> || HEQS "Heavy Equipment" Set - Revision 243: Change: support for changing properties on refit for... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/243> || Redmine - Revision 3454: Escape href attribute in auto links (#5179). <http://dev.openttdcoop.org/projects/redmine/repository/revisions/3454> || Redmine - Revision 3453: Fixes permission check in QueriesController (#5181). <http://dev.openttdcoop.org/projects/redmine/repository/revisions/3453> 10:26:17 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 245: Change: renamed file <http://dev.openttdcoop.org/projects/heqs/repository/revisions/245> 10:42:19 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 248: Change: use more defines in tram wagon template <http://dev.openttdcoop.org/projects/heqs/repository/revisions/248> || HEQS "Heavy Equipment" Set - Revision 247: Fix: mistake with word/byte confusion in industrial ... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/247> || HEQS "Heavy Equipment" Set - Revision 246: Changed: moved action 2/3 code to template for tram ... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/246> 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... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/249> 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... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/252> || HEQS "Heavy Equipment" Set - Revision 251: Change: industrial tram locomotives use templates <http://dev.openttdcoop.org/projects/heqs/repository/revisions/251> || HEQS "Heavy Equipment" Set - Revision 250: Add: template for industrial tram locomotives <http://dev.openttdcoop.org/projects/heqs/repository/revisions/250> 11:44:26 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 253: Change: tidied varact 2 chain for tram locomotive <http://dev.openttdcoop.org/projects/heqs/repository/revisions/253> 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/254> 12:48:37 <Webster> Latest update from devactivity: Nutracks - Bug #865 (New): Track costs are inconsistent and exploitable <http://dev.openttdcoop.org/issues/865> || HEQS "Heavy Equipment" Set - Revision 255: Change: refit / length / position set for Industrial... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/255> 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... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/256> 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/257> 14:23:27 <Ammler> no 14:23:36 <planetmaker> I don't understand 14:24:04 <Ammler> we keep wiki.openttd.org/OpenGFX 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> http://binaries.openttd.org/bananas/OpenGFX-0.2.1.tar.gz <- 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 http://mz.openttdcoop.org/hg/opengfx/raw-file/tip/docs/readme.ptxt 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 <http://dev.openttdcoop.org/issues/840#change-2355> || OpenGFX - Feature #771 (Closed): bundle md5 for source releases and check for them. <http://dev.openttdcoop.org/issues/771#change-2354> 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: http://qa.debian.org/developer.php?login=matthijs%40stdin.nl&set=yes&bugs=0&version=0&ubuntu=0&excuses=0&bin=0&buildd=0&problems=0&popc=1&watch=0§ion=0&ordering=0&uploads=0&packages=&uploader=&mirror=http%3A%2F%2Fftp.debian.org%2Fdebian 15:02:24 <Webster> Title: Debian Developer's Packages Overview -- Debian Quality Assurance (at qa.debian.org) 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 <http://dev.openttdcoop.org/issues/662#change-2356> 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: http://rbijker.net/openttd/fix_full_rebuild.diff <- 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> http://qa.debian.org/developer.php?login=matthijs@stdin.nl#openttd <-- 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... <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/397> || Example NewGRF Project - Feature #866 (Assigned): Clean the txt files which are generated from pt... <http://dev.openttdcoop.org/issues/866> || HEQS "Heavy Equipment" Set - Revision 259: Add: psd for tram wagons <http://dev.openttdcoop.org/projects/heqs/repository/revisions/259> || HEQS "Heavy Equipment" Set - Revision 260: Add: pcx files for trams <http://dev.openttdcoop.org/projects/heqs/repository/revisions/260> || HEQS "Heavy Equipment" Set - Revision 258: Change: test locomotive and wagons for industrial tram <http://dev.openttdcoop.org/projects/heqs/repository/revisions/258> 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> http://rbijker.net/openttd/debian_and_fedora_users_would_be_happy.diff 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 sample.cat 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 (renum.pl) 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... <http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/80> 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 sample.cat 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) <http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/81> || OpenGFX - Revision 398: Change: Make Debian and Fedora users happy (Rubidium) <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/398> 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 <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/399> 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: http://paste.openttd.org/225411 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/262> || HEQS "Heavy Equipment" Set - Revision 261: Change: tram coal car all angles <http://dev.openttdcoop.org/projects/heqs/repository/revisions/261> 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> http://83.243.128.249/error.png 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/263> 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> http://dev.openttdcoop.org/projects/home/wiki/Setting_up_a_Compile_Environment_%28Windows%29#Adding-everything-to-the-PATH-Environment-Variable 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> http://83.243.128.249/error.png 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... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/264> 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 ... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/265> 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/268> || HEQS "Heavy Equipment" Set - Revision 267: Change: make being weird after a file rename - shuff... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/267> || HEQS "Heavy Equipment" Set - Revision 266: Change: renamed pcx, resized some wagons <http://dev.openttdcoop.org/projects/heqs/repository/revisions/266> 19:01:20 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 269: Change:tweaks to industrial tram hp etc <http://dev.openttdcoop.org/projects/heqs/repository/revisions/269> 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... <http://dev.openttdcoop.org/projects/heqs/repository/revisions/270> 20:04:12 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 271: Change: improved texts for tram 1 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/271> || OpenMSX - Revision 39: Feature: 'Train filled with cash' by imuh3 <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/39> || OpenMSX - Revision 38: Change: Reorder songs a bit <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/38> || OpenMSX - Revision 37: Change: Replace 'Rubens Random Kingodom' by 'Run For Your Life' (both Tist... <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/37> || OpenMSX - Revision 36: Change: Replace 'Simple ride' by 'Ultimate run' (both Tistou Blomberg) <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/36> || OpenMSX - Revision 35: Change: Replace 'Wandering Dark Castle' by 'Coconut Run 2' (both Tistou Bl... <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/35> || OpenMSX - Revision 34: Feature: Add -lucas-' title theme <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/34> || OpenMSX - Revision 33: Change: rename 'Smooth Groove's file matching the song name <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/33> 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 <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/43> || OpenMSX - Revision 42: Fix: Readme wouldn't show the repo's title anymore <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/42> || HEQS "Heavy Equipment" Set - Revision 272: Feature: Kreuzberg Industrial Tram <http://dev.openttdcoop.org/projects/heqs/repository/revisions/272> || OpenMSX - Revision 41: Fix: Installing a tar won't work, we need to install the dir directly <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/41> || OpenMSX - Revision 40: Fix: Install in the gm dir, not in the data dir <http://dev.openttdcoop.org/projects/openmsx/repository/revisions/40> 20:36:08 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 273: Change: Kreuzberg tram loco better at 3/8 length <http://dev.openttdcoop.org/projects/heqs/repository/revisions/273> 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/275> || HEQS "Heavy Equipment" Set - Revision 274: Change: support for Henningsdorf tram locomotive <http://dev.openttdcoop.org/projects/heqs/repository/revisions/274> || #openttdcoop - Revision 46: [chroots] Add: chroot to build grfs (dummy rpm spec) <http://dev.openttdcoop.org/projects/home/repository/revisions/46> || #openttdcoop - Revision 45: [OpenTTD] Change: file transfer via ssh <http://dev.openttdcoop.org/projects/home/repository/revisions/45> 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 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/279> || HEQS "Heavy Equipment" Set - Revision 278: Change: bigger sprites for tram wagon 2 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/278> || HEQS "Heavy Equipment" Set - Revision 277: Change: tram wagon 2 features correct refit capacities <http://dev.openttdcoop.org/projects/heqs/repository/revisions/277> || HEQS "Heavy Equipment" Set - Revision 276: Add: pcx for tram wagons 2 <http://dev.openttdcoop.org/projects/heqs/repository/revisions/276> 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