Times are UTC Toggle Colours
00:09:18 <Webster> Latest update from devactivity: FISH - Revision 256: Change: fix running cost on Small Coaster <http://dev.openttdcoop.org/projects/fish/repository/revisions/256> 00:39:06 *** KenjiE20 has quit IRC 01:12:00 *** OwenS has quit IRC 02:01:33 <Webster> Latest update from devactivity: OpenGFX - Feature #869: GUI: debug icon <http://dev.openttdcoop.org/issues/869#change-2362> 02:49:17 *** Doorslammer has quit IRC 06:25:52 *** ODM has joined #openttdcoop.devzone 06:58:03 *** ODM has quit IRC 07:06:09 <Webster> Latest update from devactivity: OpenGFX - Feature #869: GUI: debug icon <http://dev.openttdcoop.org/issues/869#change-2363> 08:04:19 *** Seberoth has joined #openttdcoop.devzone 08:33:41 <andythenorth> morning 08:41:53 *** DJNekkid has quit IRC 08:57:35 *** DJNekkid has joined #openttdcoop.devzone 09:08:53 *** OwenS has joined #openttdcoop.devzone 09:30:26 <Webster> Latest update from devactivity: OpenGFX - Feature #869 (Closed): GUI: debug icon <http://dev.openttdcoop.org/issues/869#change-2364" target="_blank">http://dev.openttdcoop.org/issues/869#change-2364> || OpenGFX - Revision 401: Feature [#869]: include gui icon for debug tools <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/401> || OpenGFX - Feature #869 (Closed): GUI: debug icon <http://dev.openttdcoop.org/issues/869> 09:36:31 <Rubidium> yay! :) 09:46:57 <planetmaker> good morning 09:47:14 <OwenS> Does openttdw.grf have one too? 09:47:36 <Rubidium> the one in the ottd_grf section does 09:47:49 <Rubidium> openttd[dw].grf will 'soon' 09:48:01 <Rubidium> be in trunk 09:48:13 <Ammler> this is from there :-) 09:50:04 <planetmaker> hm, should the credits section / authors' list not mention it? 09:50:17 <planetmaker> or rather the author? 09:50:33 <Ammler> yes, I edited already 09:50:57 <planetmaker> ah :-) cool 09:51:16 <Ammler> forgot it :'-( 09:51:53 <planetmaker> nvm. Add my real name also to the credits in the same commit ;-) Then the commit has more than one reason and it doesn't show :-P 09:52:23 <Ammler> do you write von or Von? 09:52:40 <planetmaker> von 09:55:44 <planetmaker> http://www.tt-forums.net/viewtopic.php?f=68&t=47778 ah, what a subtle way of writing... 09:55:45 <Webster> Title: Transport Tycoon Forums • View topic - Layered ground tiles for stations, buildings and ind. tiles (at www.tt-forums.net) 10:18:36 <Webster> Latest update from devactivity: OpenGFX - Revision 402: Doc: update credits and blame list <http://dev.openttdcoop.org/projects/opengfx/repository/revisions/402> 10:34:39 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 304: Change: trams use defines for buy menu str IDs <http://dev.openttdcoop.org/projects/heqs/repository/revisions/304> || HEQS "Heavy Equipment" Set - Revision 303: Change: started sprite work for XXL Tractor <http://dev.openttdcoop.org/projects/heqs/repository/revisions/303> 11:13:41 *** frosch123 has joined #openttdcoop.devzone 11:19:21 *** Seberoth has quit IRC 11:28:00 *** KenjiE20 has joined #openttdcoop.devzone 12:21:02 <planetmaker> Ammler: there's one big 'contra' for OpenGFX+ within the openGFX dir: the tags ;-) 12:42:58 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 305: Change: buy menu texts for trams are now DC ids <http://dev.openttdcoop.org/projects/heqs/repository/revisions/305> 12:43:08 *** Seberoth has joined #openttdcoop.devzone 13:01:08 <Ammler> planetmaker: the tags will be called opengfx-0.2.1 and opengfxplus-0.1.0 13:01:31 <planetmaker> well... that will need to change the whole versioning scheme, too 13:02:02 <planetmaker> and is not backward compatible with the current opengfx tags 13:02:12 <planetmaker> (except if we rename them) 13:02:20 <Ammler> well, not rename but alias 13:02:37 <planetmaker> hm... 13:03:02 <planetmaker> something completely different: do we have a cargodist server directory on our server? 13:03:04 <Ammler> (if necessary) 13:03:10 <planetmaker> something like IS2's dir? 13:03:23 <Ammler> in ~/git 13:03:44 <planetmaker> that doesn't exist 13:03:59 <planetmaker> git-repos 13:05:49 <planetmaker> hm, that has no autopilot yet 13:06:42 <Ammler> svn-dev might have 13:06:50 <Ammler> a cargodist.cfg 13:06:56 <planetmaker> let's see :-) 13:07:16 <Ammler> we ran it once, I know 13:07:28 <planetmaker> yes, I know, too :-) 13:07:40 <planetmaker> I offered fonsinchen to use the dev server for testing. I gave him/her ssh 13:08:02 <Ammler> her :-o 13:09:32 <Ammler> well, cargodist doesn't really need our help :-) 13:09:40 <Ammler> it is enough popular without... 13:09:55 <Ammler> and not really playable in MP 13:10:41 <planetmaker> Well, but for the reason to test MP, that's why I offered it :-) 13:10:56 <planetmaker> That's probably cargodist's weak and worse tested part. 13:11:48 <Ammler> well, it isn't buggy, it is more just the gametype isn't compatible 13:11:56 <Ammler> it doesn't run by itself 13:12:23 <Ammler> cargodist needs a lot of micromanagemnet 13:12:52 <Ammler> that is what took my attention out of it 13:13:14 <Ammler> but I am of course fine with testing it furhter... :-) 13:14:09 <planetmaker> Well... I haven't myself tested it much, I have to say. But... yeah, I don't mind if our testing environment is used. 13:14:20 <planetmaker> It helps cargodist and in a way also us :-) 13:34:04 *** Seberoth has quit IRC 13:54:24 <planetmaker> Just FYI (I'll be offline now a bit): Ammler and Kenji20 also know their way around the servers. Possibly also SmatZ 13:54:51 <planetmaker> hm... that was meant for fonsinchen ;-) 14:03:11 <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 307: Fix: corrected refit strings for trams <http://dev.openttdcoop.org/projects/heqs/repository/revisions/307> || HEQS "Heavy Equipment" Set - Revision 306: Changed: use defines for tram 1 refit texts <http://dev.openttdcoop.org/projects/heqs/repository/revisions/306> 15:40:21 *** DJNekkid has quit IRC 15:57:40 *** DJNekkid has joined #openttdcoop.devzone 16:12:50 *** DJNekkid has quit IRC 16:25:04 *** DJNekkid has joined #openttdcoop.devzone 16:43:32 <Webster> Latest update from devactivity: Example NewGRF Project - Feature #870 (Assigned): Support branches within a repository <http://dev.openttdcoop.org/issues/870> 17:03:07 *** Doorslammer has joined #openttdcoop.devzone 17:08:57 * planetmaker ponders to use branches within OpenGFX. Not now, but possibly then 17:09:37 <planetmaker> would make it easier to just go forward - and only re-import those changes to a release which are reasonably tested or a bug fix 17:10:28 <planetmaker> or maybe even now... 17:14:37 <planetmaker> how bad would it be? 17:14:41 <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Revision 755: Fix: Oil Refinery tiles were incorrectly accepting ... <http://dev.openttdcoop.org/projects/firs/repository/revisions/755> 17:16:18 <Ammler> planetmaker: if we do branch, then something like 2 branches "work" and "stable" 17:17:07 <Rubidium> I think you should make branches for each stable branch 17:17:13 <Rubidium> i.e. like OpenTTD 17:17:16 <Ammler> version branch is only needed, if the opengfx become uncompatible 17:17:40 <Ammler> Rubidium: but we don't introduce experimental things 17:18:08 <Ammler> the only thing we do is replacing sprite 17:18:15 <Ammler> sometime a bit alignment 17:18:21 <Rubidium> Ammler: but at some point you want to take everything from thw "work" branch to the "stable" branch, i.e. you're branching off the "work" branch 17:18:23 <planetmaker> Ammler: yes. Which might set up new alignment problems and alike 17:19:08 <planetmaker> Like now... I'm not sure I should continue with an entirely new part of the trains, adding new sprites. 17:19:23 <Ammler> then do it in a branch :-) 17:19:41 <planetmaker> It will be like fiddling with lots of offsets and so on 17:20:06 <Rubidium> but that's more the other way around: introducing "feature" branches that you want to merge with the main branch 17:20:23 <Rubidium> i.e. a branch for each non-trivial set of changes 17:21:00 <planetmaker> the transplant extension makes it actually even quite easy to transplant trunk changes to a release branch. 17:21:15 <planetmaker> For those which are considered worth a bug fix release 17:21:38 <Rubidium> sounds like cherry picking commits to "backport" :) 17:21:48 <planetmaker> It might also give the bigger OpenGFX releases more of an impact with the bigger releases 17:21:56 <planetmaker> Rubidium: well... that's how it works ;-) 17:21:58 <Rubidium> not sure how well that works with binary files 17:22:01 <planetmaker> Isn't that what you do, too? 17:22:21 <Ammler> mostly only bugfixing... 17:22:26 <planetmaker> Well... one will have to see how well that works. Probably not too well. 17:22:35 <Rubidium> planetmaker: yes, but once a year we abandon the "stable" branch and make a new one based on the main branch 17:22:50 <planetmaker> another reason actually to separate sprites into their own files 17:23:02 <Ammler> why does that need branch? 17:23:58 <Rubidium> Ammler: do a "hg branches" to find out 17:24:47 * Rubidium envisions Ammler running around with the thought "I didn't do a branch, but I have a branch... what went wrong?!?" 17:25:19 <Rubidium> but I didn't name my branch right, so s/main/default/ 17:25:39 <planetmaker> default branch has no name with hg. That's fine actually 17:25:54 <Ammler> well, default it is 17:25:57 <planetmaker> The release branches don't need much care after the initial release of 0.x.0 17:26:35 <planetmaker> Ammler: not if you call hg log --template='{rev}-{branches}: {desc}\n' ;-) 17:28:08 <Ammler> well, it is mainly up2you (release managers) 17:28:14 <planetmaker> Ammler: one thing I see which we could change is when we put "big features" into a release 17:28:28 <Ammler> as backporting would be the task of you 17:28:31 <planetmaker> Like all these new trans and vehicles. Or really more climate specific. 17:28:36 <planetmaker> Yeah :-P 17:28:57 <Ammler> planetmaker: IMO, there will never be "big features" :-D 17:29:15 <planetmaker> Don't you think that nearly re-drawn trains is a 'big feature'? 17:29:22 <planetmaker> Or new tropical and arctic houses? 17:29:44 <Rubidium> Ammler: you didn't make "big feature" conceptually wide enough :) 17:30:01 <Rubidium> Ammler: splitting all sprites into templates would be a "big feature" 17:30:16 <Ammler> and if there will be, we can make branch then... :-) 17:30:21 <Rubidium> it would take a few months, maybe a year. After that it needs some proper testings and such 17:31:20 <OwenS> I suppose a graphics set is rather different from a software project 17:31:25 <Rubidium> meanwhile you want to be able to fix the occasional glitch / add a few new sprites without having to stabilize your development/default branch 17:31:45 <planetmaker> Ammler: Exactly. With such big changes done and tested, we can go for a new major release. And what Rubi says. 17:32:04 <planetmaker> Hm... we could test it right now :-) 17:32:13 <Rubidium> OwenS: normal NewGRFs are more or less a software project, only OpenGFX, OpenSFX and OpenMSX aren't 17:32:21 <planetmaker> That branch 0.2 won't hurt us. Everyone can go on with default as usual 17:32:39 <Ammler> IMO, branches makes much more sense with FIRS or 2cc or whatever 17:32:51 <planetmaker> OwenS: for reference: FIRS has 12000 sprites. 3500 are real sprites. 17:33:14 <Rubidium> Ammler: true, but that's because it's more a software project than OpenGFX et al. 17:33:29 <planetmaker> Ammler: yes, there it makes even more sense 17:33:38 <Ammler> but as said initially, 17:33:39 <OwenS> With OpenTTD, you you forward port or backport fixes? 17:33:54 <Ammler> back 17:33:59 <Rubidium> OwenS: from trunk to stable branch 17:34:02 <planetmaker> ^ what commit messages say 17:34:25 <planetmaker> (and time stamps) 17:34:35 <OwenS> Heh; we tend to do the other way 'round (But then again, Git makes forwardporting really easy, but backporting requires cherry picking and is error prone) 17:34:44 <planetmaker> http://paste.openttd.org/225420 <-- that's how it could look like, Ammler 17:35:11 <Ammler> planetmaker: for me, it would just mean helping like now 17:35:21 <planetmaker> Ammler: yeah :-) 17:35:33 <Ammler> and you or foobar (or Rubidium) would do the needed backport 17:35:41 <planetmaker> Basically yes 17:36:01 <Rubidium> OwenS: anyhow, OpenSFX et al. are special because they have more or less arrived at what they can be; the only things that can be done now are for maintainability and the occasional sprite update. They won't be getting any new major features 17:36:34 <Ammler> sfx could have GPL sounds as "big feature" ;-) 17:36:45 <planetmaker> :-) 17:36:59 <Ammler> for 1.0.0 :-) 17:37:03 <OwenS> Rubidium: It's true 17:37:05 <Rubidium> Ammler: but that is no branch, that's just starting from scratch 17:37:19 <planetmaker> Rubidium: it could be a gradual replacement 17:37:23 <OwenS> OpenGFX just needs new graphics adding to match openttdw.grf 17:37:29 <Ammler> aren't already some samples gpl? 17:38:05 <Rubidium> Ammler: none are GPL; you can't have some GPL and some not GPL as they're kinda 'linked' together in a binary file 17:38:13 <Ammler> OwenS: well, we do also complete replacement, e.g. train engines 17:38:19 <Rubidium> which causes all kinds of legal shit 17:38:40 <OwenS> Rubidium: Well, unless the non-GPL can be implicitly relicensed under the GPL :p 17:38:53 <planetmaker> OwenS: well... not entirely 17:39:17 <planetmaker> OpenGFX is more than 'just' graphics. Though 95% are graphics and their respective alignment 17:39:20 <Rubidium> OwenS: but then ALL are GPL (or freeer) 17:39:28 <OwenS> Rubidium: Yes 17:40:16 <OwenS> (Sidenote: There is nothing more irritating than a GPLed library. For example. libbfd, LD's backend) 17:41:07 <Ammler> planetmaker: for me it would make prefectly sense to add main version branch, if opengfx get incompatible 17:41:23 <Ammler> but because that isn't the case, I would work with "feature" branches 17:41:36 <Rubidium> anyhow, forward porting requires that you commit all fixes in the "stable" branch even though those fixes can be unstable. You'd also need to postpone committing fixes or branch the stable branch to bridge the gap between RC and actual release 17:42:38 <Rubidium> and if you actively use trunk and not the stable branch, you might need to merge pretty often 17:43:20 <Rubidium> anyhow, both ways have their benefits and drawbacks. I'm happy with backporting in svn; works quite nice actually 17:44:04 <Ammler> I don't think, it would work well with opengfx 17:44:05 <Rubidium> svn merge -c <list of trunk commits> ^/trunk (is quite reasonable for cherry picking I'd say) 17:44:34 <Ammler> for example, you splitted the pcx, which you don't backport 17:44:52 <OwenS> The stable branch in our case is the "release engineering" branch, which means it should be close to what we release but may have bugs. We release when we have closed all bugs marked for that release, and a certain time has passed without any new changes committed 17:44:58 <Ammler> then you have a single GUI addon 17:45:10 <OwenS> For us, its "git pull v1-0", for example 17:45:12 <planetmaker> Ammler: that's a major feature then ;-) - not everything needs backport 17:45:39 <Rubidium> Ammler: I agree, porting any way with graphics files is very non-trivial (or rather the merging of changed graphics files) 17:45:43 <Ammler> oh, so you would make the branches related to openttd? 17:46:12 <OwenS> We then look in depth at any conflicts 17:46:13 <Ammler> so like ogfx_for_ottd_1.0 17:46:56 <Ammler> planetmaker: I would quite much bet, you have to make the work twice 17:47:14 <Ammler> (those which need in stable) 17:49:04 <planetmaker> Ammler: partially 17:49:37 <Ammler> this discussion is very much related to the 1.0 discussion we already have on the tracker... 17:49:41 <planetmaker> But I wouldn't make branches relating to OpenTTD. I would branch when we think that there's a major new feature 17:50:14 <planetmaker> and that feature is ok. Then we can release a major version e.g. 0.3 and then continue with other majore stuff. 17:50:24 <Ammler> this could be for example oil wells with Action2 :-) 17:50:41 <planetmaker> The minor things will be copied over to bug fix releases and additonal GUI sprites as they become necessary 17:50:45 <Ammler> s/ell/eel/ 17:51:12 <planetmaker> oil wells is correct ;-) 17:51:18 <Ammler> hmm :-D 17:51:21 <planetmaker> they don't usually have wheels :-P 17:51:35 <Ammler> I see :-P 17:51:57 <Rubidium> to be honest, I don't think branches are really maintainable unless you have all graphics files reasonably split up 17:52:25 <Ammler> and splitting those doen't need be a reason for branch 17:52:36 <Ammler> to* 17:53:21 <Ammler> planetmaker: if you experiment something, you could make a local fork 17:53:26 <Ammler> (or branch) 17:53:36 <planetmaker> hm, yes. 17:53:37 <Ammler> then push it when done 17:54:04 <planetmaker> but then the backdraw is: no nightlies ;-) 17:54:13 <Ammler> if you like to show your fork, nobody stops you from doing that ^ 17:54:48 <Ammler> hmm, those dvcs portals used to say make a pull request 17:54:59 <planetmaker> hu? 17:55:17 <Ammler> if you don't have commit rights to the official branch 17:55:25 <OwenS> push request you mean? 17:55:25 <Ammler> you make your onw repo (branch) 17:55:29 <Ammler> no 17:55:40 <OwenS> Oh, online forks 17:55:41 <Ammler> you need to tell the dev that he pulls from you 17:55:48 <OwenS> Aah 17:55:51 <Ammler> as you can't push 17:56:01 <Ammler> well, I think, it works that way, never done :-) 17:56:05 <OwenS> Gitorious has something better: Merge requests. You push to a special URL and it creates a merge request 17:56:48 <Ammler> in our case, pm does simply clone "hg clone opengfx opengfx-oil-weels" 17:57:01 <planetmaker> right... I've never seen that done either, Ammler :-) 17:57:14 <planetmaker> Ammler: no, I'd try for a change hg branch :-P 17:57:16 *** Seberoth has joined #openttdcoop.devzone 17:57:28 <planetmaker> well... I'll see 17:57:40 <Ammler> that might save space 17:57:55 <planetmaker> well.... HDD space is not the real issue to be honest ;-) 17:58:06 <Ammler> but merging isn't easier 17:58:52 <Ammler> many hg repos have branch like stable and work 17:59:00 <Ammler> or however "work" is called 17:59:14 <Ammler> could be default 17:59:28 <planetmaker> default is what is used, if nothing is defined 18:00:35 <OwenS> Ammler: You push to your Gitorious clone, go there, and select "Merge request", and then tell the devs some details 18:00:39 <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Bug #871 (New): Some stations built un-named <http://dev.openttdcoop.org/issues/871> 18:01:36 <Ammler> OwenS: yeah, well, pull is a part of merging from an other repo 18:01:58 <OwenS> Ammler: Yes, but merge requests structures things very well 18:02:37 <Ammler> you pull and create a kind of branch from same parent and then merge those heads 18:03:52 <OwenS> With git you'd normally just pull from the repository you want and it would automatically merge them... 18:04:20 <Ammler> ah indeed hg pull is like git fetch, afaik 18:04:38 <Ammler> git pull is hg pull && hg merge 18:04:55 <Ammler> or so 18:05:20 <Ammler> OwenS: we need a git repo on our devzone 18:05:27 <Ammler> we have no experience with it ;-) 18:05:40 <OwenS> Ammler: Set it up for Git, and I'll push progsigs there ;-) 18:06:01 <OwenS> (As well as Gitorious) 18:06:08 <Ammler> redmine has much better git support than hg 18:06:27 <Ammler> all devs there work with svn or git 18:06:41 <OwenS> Though... hmm... I'll need to associate two pubkeys with my account 18:06:54 <Ammler> that is no issue 18:07:12 <OwenS> (One my server uses for automated pushes, and one in the case I myself want to touch the repo) 18:07:46 <Ammler> I have one key there for repos without passphrase and one with full ssh access with 18:13:36 <Ammler> hmm, no git pull is like hg pull && hg up 18:13:48 <Ammler> and git fetch is hg pull 18:14:05 <Ammler> nothing to do with merge... 18:39:26 *** ODM has joined #openttdcoop.devzone 21:21:47 <planetmaker> interesting on what things hg seems to depend for unknown reasons... 21:22:38 <planetmaker> I wouldn't have bet that freetype was one of it nor xorg-libX11. Stupid macports... 21:23:15 * planetmaker nevertheless now has hg 1.5 21:26:21 <planetmaker> ah. hm. That's now python 2.6 based 21:28:46 <OwenS> Git only depends on things like that if you use git gui :p 21:40:05 <planetmaker> OwenS: I'm quite sure hg usually does, too. Like it should only depend upon python. 22:32:52 *** ODM has quit IRC 23:32:56 *** Seberoth has quit IRC 23:39:34 *** frosch123 has quit IRC 23:45:51 *** DJNekkid has quit IRC