Log for #openttdcoop.devzone on 27th March 2010:
Times are UTC Toggle Colours
00:09:18  <Webster> Latest update from devactivity: FISH - Revision 256: Change: fix running cost on Small Coaster <>
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 <>
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 <>
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 <" target="_blank">> || OpenGFX - Revision 401: Feature [#869]: include gui icon for debug tools <> || OpenGFX - Feature #869 (Closed): GUI: debug icon <>
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> 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
10:18:36  <Webster> Latest update from devactivity: OpenGFX - Revision 402: Doc: update credits and blame list <>
10:34:39  <Webster> Latest update from devactivity: HEQS "Heavy Equipment" Set - Revision 304: Change: trams use defines for buy menu str IDs <> || HEQS "Heavy Equipment" Set - Revision 303: Change: started sprite work for XXL Tractor <>
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 <>
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 <> || HEQS "Heavy Equipment" Set - Revision 306: Changed: use defines for tram 1 refit texts <>
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 <>
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 ... <>
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> <-- 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 <>
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

Powered by YARRSTE version: svn-trunk