Config
Log for #openttdcoop.devzone on 5th June 2011:
Times are UTC Toggle Colours
04:35:29  <Brot6> Bundles Update: g4dd2678f 2011-06-05 cargodist   (http://bundles.openttdcoop.org/cargodist)
06:47:01  *** ODM has joined #openttdcoop.devzone
07:58:27  *** frosch123 has joined #openttdcoop.devzone
09:21:03  *** Alberth has joined #openttdcoop.devzone
09:22:49  <Alberth> Terkhen: You changed #2685 to feedback, what does that mean?
09:22:49  <Brot6> Alberth: Terkhen: #2685 is http://dev.openttdcoop.org/issues/show/2685 "OpenGFX+ Industries - Code Review #2685: english.lng remarks - #openttdcoop Development Zone"
09:23:10  <planetmaker> Alberth: it means: check out how you like current trunk
09:23:27  <planetmaker> or in this case 0.3.4
09:23:34  <Terkhen> Alberth: we implemented most of the changes (and a few more), please review the file to see if further changes are needed :)
09:23:38  <planetmaker> whether that addresses the issue in the sense you meant the bug report
09:23:59  <planetmaker> or in other words: "feedback welcome" :-)
09:24:16  <Alberth> ah, ok :)
09:24:26  <planetmaker> and if you say "all fine" - it can be closed
09:24:28  <Alberth> dutch also needs fixing, I guess :)
09:24:42  <planetmaker> maybe :-) It would need a Dutchie to do so, though
09:24:50  <planetmaker> tralallalala :-)
09:25:19  <Alberth> like my Dutch is any good :p
09:25:31  <Alberth> I write and read way too much English :)
09:52:07  <Ammler> "Resolved" is for that case
09:52:44  <planetmaker> Ammler: that is for alberth to change the status into
09:52:55  <Alberth> is there a wiki page about them?  I find those states quite confusing
09:53:25  <Terkhen> me too :P
09:53:47  <planetmaker> I guess there is not quite... https://dev.openttdcoop.org/issue_statuses <-- is that readable for you?
09:54:31  <Terkhen> You are not authorized to access this page. <-- it is readable, but not very informative :)
09:54:44  <Alberth> :p
09:54:45  <planetmaker> :-P
09:54:51  <Ammler> planetmaker: that is just a list
09:55:39  <Ammler> Alberth: basically you can define the statuses project based
09:55:40  <Alberth> 'is not quite' would a good description thus :)
09:55:58  <planetmaker> http://imagebin.org/156856 <-- that's the list
09:56:04  <Webster> Title: Imagebin - A place to slap up your images. (at imagebin.org)
09:56:05  <planetmaker> and the list basically is the "workflow"
09:56:05  <Ammler> using Resolved instead close was just a suggestion
09:56:37  <planetmaker> new -> confirmed ->( assigned) -> feedback -> resolved -> closed
09:56:43  <planetmaker> -> reopened :-P
09:57:15  <planetmaker> someone obviously at a later stage added "can_be_closed". Which doesn't make sense to me ;-)
09:57:20  <Ammler> feedback turns the ticket into a forum
09:57:30  <planetmaker> ?
09:57:37  <Ammler> resolved tells the reporter to check and close
09:57:49  <planetmaker> nope. That's feedback
09:57:54  <planetmaker> or should be
09:58:04  <planetmaker> or at least that's how I use it ;-)
09:58:38  <Ammler> yeah, that is why I told you what resolved is for
09:59:00  <Alberth> confusion is live demonstrated here ;)
09:59:10  <Ammler> as said, it can be ruled by project independently
09:59:26  <Alberth> does any of them do that?
09:59:31  <Ammler> Alberth: not confusing, flexibility :-P
09:59:57  <Alberth> :)
10:00:22  <Ammler> resolved basically also need assignment to tell who has to close it
10:01:09  <Alberth> I'd just close it after discussion at the IRC
10:01:22  <planetmaker> yes. or that
10:01:46  <planetmaker> but sometimes there are people who don't use IRC much. That's where these stages can help to communicate
10:02:01  <Ammler> yep, that is needed on feedback, as it isn't clear
10:02:08  <Ammler> resolved it is clear, imo :-)
10:02:25  * Alberth finds 'can be closed' more clear
10:02:32  <planetmaker> Ammler: but if I fix something, the issue is not 'resolved'. Only the person who found the bug can confirm 'resolved'
10:02:41  <Ammler> can_be_closed is no workflow status afaik
10:02:44  <planetmaker> or 'can be closed'. It's equivalent to me
10:02:56  <Ammler> planetmaker: wrong
10:03:02  <Ammler> the reporter does close it
10:03:07  <Alberth> planetmaker: your state would be 'please confirm fix' or so
10:03:19  <Ammler> you fix it and set to resolved and assign to reporter
10:03:28  <Ammler> reporter then does review and close
10:04:02  <Alberth> Ammler: is there a wiki page about how we are supposed to work with the ticket system?
10:04:35  <planetmaker> nope
10:05:04  <Ammler> Alberth: again, it can be done how you like it so we could make a wiki page for the devzone
10:05:07  <planetmaker> Ammler: reporter closes? That'd be something quite new. I don't think the reporter closes is a good thing. It'd leave many tasks open ;-)
10:05:52  <planetmaker> though... would save work. so maybe it's good
10:06:01  <Ammler> planetmaker: workflow is new-confirmed-assigned-resolved-feedback-closed
10:06:24  <Ammler> planetmaker: if a dev does report a bug
10:06:39  <Ammler> I would set it to resolved instead close myself
10:07:04  <Ammler> if the reporter is some strange guy, I most probalby just close myself
10:07:13  <Ammler> (he could still reopen)
10:08:34  <Alberth> but I have no desire in changing it, I am sure you or others have thought about it for a long time. I am just confused, and am looking for a way to end this confusion
10:09:02  <planetmaker> I'd not be too sure about "thought about it for _long_ time"
10:09:09  <Ammler> well, I guess esiest is to not use "resolved" for you
10:09:25  <Ammler> it was just a try to explain difference of feedback and resolved by me :-)
10:09:27  <planetmaker> most notably nearly no-one ever uses it ;-)
10:10:18  <Ammler> feedback is open, resolved should be assigned and closed if assigny is fine wiht
10:10:23  <Terkhen> I usually use only closed
10:10:26  <Terkhen> :P
10:10:32  <planetmaker> so do I
10:10:43  <Ammler> so is the case in 95%
10:10:59  <Alberth> but at the same time, I'd like to do things in a way that everybody understands, so ignoring a state just because I fail to understand it is just working around the problem, and may cause more confusion than it solves
10:11:28  <planetmaker> :-) We should document one way - and then stick to that.
10:11:32  <Ammler> Alberth: it is easy, if you like feedback for a ticket you worked on, set it to it :-)
10:11:40  <planetmaker> A "every project can configure it" won't bring us any further
10:11:51  <Terkhen> yes, documenting one way would be nice
10:12:12  <Alberth> Ammler: 'easy' implies understanding of its meaning, which is what I am lacking
10:12:47  <planetmaker> basically our problem is proper naming, I think.
10:12:53  <Ammler> Alberth: resolved is basically review and close, feedback is open talk about
10:12:57  <Alberth> or a reduction to 'new', 'confirmed', and 'closed'  :p
10:12:57  <planetmaker> new -> confirmed -> assigned is clear, I think
10:13:11  <Terkhen> yes
10:13:32  <planetmaker> so. next would need some work by someone working on it - and then feedback of *some* form is needed. Whether it's fixed now already completely or not
10:13:57  <planetmaker> I also would set an issue to "feedback" when I just comment on alternative ways how to solve an issue
10:14:03  <Ammler> planetmaker: if you like something else, it could be possible, the workflow can be changed
10:14:12  <planetmaker> I know.
10:14:35  <Alberth> Ammler: you typically want a single workflow for everything, otherwise you get crazy
10:14:38  <planetmaker> I'm not talking about how things are, but how it could be handled. Independent of how issues are treated now
10:14:50  <Ammler> http://www.redmine.org/projects/redmine/wiki/RedmineIssues#Updating-an-existing-issue <-- the user guide seems not speaking much about statuses
10:14:51  <Webster> Title: Redmine - RedmineIssues - Redmine (at www.redmine.org)
10:14:56  <Ammler> since those aren't fix
10:15:39  <planetmaker> back to us: so: what shall happen when I have worked on an issue and want the reporter to comment on it - may it be "that fixes it for me" or "approach a seems fine"
10:15:41  <Ammler> Alberth: I basically meant, you can skip status like resolved if you want
10:15:57  <planetmaker> ...
10:16:02  <Terkhen> waiting on ...
10:16:28  <planetmaker> Waiting for feedback?
10:16:29  <Alberth> I am fine with any ticket workflow, it just needs a good description so I can look it up when needed, and point others to it
10:16:41  <planetmaker> Alberth: yes, agreed
10:16:45  <Terkhen> ^
10:17:01  <planetmaker> But let's also keep it simple, what is simple for you
10:17:03  <Alberth> so the current is no doubt fine
10:17:05  <Terkhen> I'd call it waiting on feedback yes, a comment can clarify it more
10:17:14  <Terkhen> but it can be kept as "feedback" too
10:17:27  <planetmaker> And then the next one can just as well be closed
10:17:35  <Ammler> feedback is something which can happen always, also before the ticket is resolved
10:17:44  <Ammler> e.g. to ask for help
10:17:50  <planetmaker> or a reporter could set it to 'can be closed'
10:17:52  <Alberth> so as state somewhat meaning less :)
10:18:08  <Ammler> planetmaker: can_be_closed is not available
10:18:20  <Ammler> well, try to find it :-)
10:18:21  <planetmaker> Ammler: I'm NOT talking of as it is.
10:18:32  <planetmaker> Please ignore any current status.
10:19:20  <Alberth> 'requires feedback'   as state?
10:19:55  <planetmaker> would the reporter change it then to something else? Or would he just change the assignment?
10:19:57  <Alberth> ie our 'waiting for reporter' state :p
10:21:32  <planetmaker> ok... so... assigned -> requires feedback (reporter action needed) -> resolved (set by dev) -> closed (set by reporter when 'resolved' is previous state or when dev thinks so)
10:21:41  <Alberth> reporter may change it to assigned or confirmed, but that implies he understands enough about the problem that he can make that decision
10:22:04  <Alberth> what is 'resolved' ?
10:22:26  <planetmaker> "Can it be closed?" state
10:22:46  <Alberth> not important enough imho
10:22:50  <planetmaker> i.e. the final feedback whether the fix is appropriate. ok
10:23:15  <Alberth> I'd use 'requires feedback' with a comment, or just close the issue.
10:23:18  <Ammler> planetmaker: resolved->closed (set by reported, if dev assigned resolved to reporter)
10:23:31  <Alberth> 'confirm fix'  ?
10:23:42  <planetmaker> good name
10:23:44  <Alberth> (if you insist)
10:23:49  <planetmaker> but I don't
10:23:57  <planetmaker> less is more :-)
10:24:10  <planetmaker> IMHO that is
10:24:11  <Alberth> you're going to write a comment anyway
10:24:11  <Ammler> well, I would really not change the statuses, just describe it
10:24:48  <planetmaker> ok, so new->confirmed->(assinged->)feedback required->closed
10:24:49  <planetmaker> that's it?
10:25:26  <Alberth> you could add several closed states
10:25:28  <planetmaker> and "feedback required" as long as there's some kind of communication required
10:25:42  <Ammler> new->feedback->assigned->feedback->feedback required (resolved)->feedback->closed->reopen
10:26:01  <planetmaker> hu?
10:26:18  <planetmaker> sounds complicated
10:26:20  <Alberth> eg invalid, wontfix
10:26:28  <planetmaker> yes, that's rejected for ;-)
10:26:31  <Alberth> yeah, very complicated
10:26:37  <Ammler> planetmaker: sometimes people make a ticket for feedback
10:26:52  <planetmaker> I've never seen such
10:27:00  <Ammler> firs has lots
10:27:11  <Alberth> Ammler: you can define a problem at several abstraction levels
10:27:47  <Alberth> Ammler: I use UQDS at work, and there you are required to make a ticket before you change any code
10:27:59  <planetmaker> may I reduce it to a 4-step process as I outlined above? - what is uqds?
10:28:22  <Alberth> ultimate quality development system :)
10:28:26  * Alberth looks for an url
10:28:49  <Ammler> planetmaker: just do it :-)
10:29:20  <Alberth> http://twistedmatrix.com/trac/wiki/UltimateQualityDevelopmentSystem
10:29:22  <Webster> Title: UltimateQualityDevelopmentSystem – Twisted (at twistedmatrix.com)
10:29:48  <Alberth> in one line: make a ticket; make a branch; fix; review code; merge to trunk
10:30:24  <Alberth> s/code/branch/
10:30:55  <Ammler> that is new; confirmed, resolved; closed
10:31:08  <Alberth> ?
10:32:15  <Ammler> make a ticket (new); make a branch (confirm, assign); fix, review code (resolved); merge to trunk (close)
10:32:16  <Alberth> actually, we have a 'review' and 'merge' state instead of 'resolved'
10:39:40  <Ammler> merge sounds quite final :-)
10:42:45  <Alberth> it is, but it is still 2 commands away from closed :)
10:44:40  <Alberth> merge is somewhat equivalent to your resolved I think. It means 'it is good enough for me'. Usually there are some other minor things to fix, such as spelling errors
10:45:06  <Ammler> who does the review part?
10:45:17  <Alberth> not the author :)
10:45:33  <planetmaker> Alberth: Terkhen Ammler http://dev.openttdcoop.org/projects/home/wiki/Workflow
10:46:16  <Alberth> which in my view is a strong point of the method, it gives you a fresh pair of eyes on your code
10:47:04  <Terkhen> looks fine to me
10:47:58  <Alberth> This status will be kept until a solution has been found and implemented <-- I'd keep it until the feedback is sufficient to continue
10:48:03  <Ammler> planetmaker: fine, you can still add "resolved" without hurting that guide
10:48:15  <planetmaker> One can actually consider the 'assigned' status as not-needed.
10:48:21  <planetmaker> after all there's an assigned field...
10:48:41  <Ammler> well, asigned basically means "working on"
10:48:53  <planetmaker> yes, that's the difference
10:49:32  <Ammler> and someone does not work on a ticket which is assigned to someone else :-)
10:49:47  <Alberth> good point, I'd remove the 'assigned' state
10:50:15  <Alberth> do you need re-open?, ie how is it different than 'confirmed' or so?
10:50:43  <planetmaker> Alberth: you use it when I fixed and close an issue - and then you find that I missed three dozen corner cases
10:50:53  * Alberth nods
10:51:01  <Alberth> but why not 'confirmed' ?
10:51:11  <Alberth> ie the problem still exists
10:51:35  <planetmaker> that'd be the next step then again. reopened is like new. Just that it's not really new
10:51:36  <Ammler> close does only allow reopn
10:52:02  <Ammler> which need first feedback before you confirm the reopen as valid
10:52:34  <Alberth> may I suggest to add 'This state is equivalent to new, but for an existing issue.'  to re-opened state?
10:52:59  <planetmaker> Yes. ;-)
10:53:26  <Alberth> Ammler: why? what if the ticket is closed by accident?
10:53:39  <Ammler> reopen is the "workaround", if you close tickets without feedback
10:55:12  <Alberth> planetmaker: euhm, if you re-open, you already have a confirmation that the issue is not fixed
10:55:45  <Ammler> Alberth: it is similar to "request reopen" on flyspray
10:55:59  <Alberth> no it is not
10:56:05  <Ammler> why not?
10:56:18  <Alberth> request re-open is a user request, not a different ticket state
10:56:44  <Ammler> yep, exactly
10:56:50  <Ammler> so?
10:57:06  <planetmaker> Ammler: a request for re-open at FS is no issue state; it does nothing
10:57:09  <Alberth> hmm, ok, I see your point. But then you'd need also close -> confirmed
10:57:22  <Ammler> planetmaker: same on devzone
10:57:42  <planetmaker> Ammler: nope. There a reporter can reopen it.
10:57:48  <Alberth> if a dev finds a problem
10:57:49  <planetmaker> on FS only a FS manager
10:58:07  <Ammler> planetmaker: because there is no "request reopen" feature :-)
10:58:28  <Ammler> do you have "reopened" state on flyspray?
10:58:43  <planetmaker> Alberth: a project manager nearly can change it as s/he likes ;-)
10:59:01  <planetmaker> so yes s/he can change from closed -> assigned or confirmed
10:59:15  <planetmaker> it's just not mentioned in that description
10:59:21  <Alberth> Ammler stated closed->re-opened  only
10:59:33  <Ammler> Alberth: workflow
10:59:47  <Alberth> but if you can work around those limitations, fine :)
11:00:08  <planetmaker> Alberth: yes... there's a difference of what a 'normal' user can do and what the project managers can do with a ticket ;-)
11:00:09  <Ammler> a manager and dev never should need reopen
11:00:18  <Ammler> that is just for reporters
11:00:24  <planetmaker> then dev would need changing. I'll do that
11:01:16  <Ammler> close->reopen->confimed or rejected
11:03:59  <Alberth> the 'rejected' case would be interesting there :)
11:04:26  <Alberth> ie what about the implemented changes then :p
11:04:43  <planetmaker> :-)
11:04:58  <Ammler> Alberth: it often happens, that devs implement a feature request in an other way the reporter expected :-)
11:06:06  <Alberth> if both ways are disjoint, the dev is working on the wrong ticket :p
11:07:29  <planetmaker> :-D "Bug: food rail wagon not available" - "Fix: Do not try to implement rail wagons at all" ;-)
11:10:13  <Yexo> Ammler: but a manager/dev can be a reporter too
11:20:12  <Ammler> Yexo: and how does that matter?
11:20:52  <Yexo> <Ammler> a manager and dev never should need reopen <_ in that case they do
11:21:14  <Ammler> if the dev or manager is not sure abour reopen, he should use reopen
11:24:43  <Ammler> Yexo: if the reporter is a dev but not the dev which fixes it, the fixer should not close, rather ask the reporter to close (resolved or feedback)
12:09:51  <Alberth> Terkhen: STR_PARAM_OIL_WELLS_DISABLE_RESTRICTIONS_DESC                   :Oil Wells will be built in temperate climate during normal gameplay, and also after the year 1950 in other climates.   <-- 'other climates' excludes toyland, right?
12:10:17  <Alberth> I am making a diff :)
12:11:36  <planetmaker> Alberth: OpenGFX+Industries doesn't yet support toyland and disables itself there. Hopefully
12:51:02  <Brot6> OpenGFX+ Industries - Code Review #2685: english.lng remarks (Alberth) @ http://dev.openttdcoop.org/issues/2685#change-6789
12:52:21  <Alberth> luckily I have not enough powers to change the state of the ticket :p
12:52:47  <Alberth> planetmaker: Where should I drop dutch language fixes?
12:53:22  <planetmaker> I'd make a ticket for that.
12:53:34  <planetmaker> or... give me a link to the patch file now :-)
12:54:14  <Alberth> but changes are depending on changes in the english.lng file
12:54:26  <planetmaker> why?
12:54:44  <planetmaker> the meaning of the setting itself doesn't change.
12:55:00  <planetmaker> Just the English description, right?
12:55:16  <Alberth> I try to stay close to the wording of english
12:55:23  <planetmaker> So you should have an easy time to provide a better Dutch language file than the English one ;-)
12:55:52  <planetmaker> Nah... translation is about getting the meaning of a setting accross. Not to translate literally ;-) (At least that's my approach)
12:56:12  <Alberth>  http://devs.openttd.org/~alberth/dutch.lng.modified   here it is :)
12:56:16  <planetmaker> Both Terkhen and myself found out that our translations were already better than the English "original" before we discussed English yesterday
12:57:10  <Alberth> keeping track of revision of the master file is a nightmare though, imho
12:57:28  <Alberth> no idea how to do that properly, short of adding a revision in the derived file
12:57:47  <Alberth> but theoretically, you'd need to state that for each string
13:08:30  <planetmaker> hm, seems there was no Dutch translation at all before :-)
13:08:40  <planetmaker> yes, it'd need that...
13:09:00  <planetmaker> but... maybe my check_languages script for FIRS also could be modified for NML... should be even easier
13:09:16  <Terkhen> it could be easily converted, but it has its own share of issues too
13:09:24  <planetmaker> quite so, yes
13:09:40  <Terkhen> it's probably better than nothing :)
13:13:50  <Yexo> that time might be better spend writing WT3.1
13:14:16  <planetmaker> he
13:14:20  <Brot6> OpenGFX+ Industries - Revision 118:5024e5642cc0: Add: Dutch language update (Alberth) (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-industries/repository/revisions/5024e5642cc0
13:14:46  * Alberth agrees
13:15:55  <Alberth> except that "W" should become optional :p
13:16:06  <Terkhen> planetmaker: the changes suggested at #2685 look fine to me, feel free to commit them too if you agree :)
13:16:06  <Brot6> Terkhen: planetmaker: #2685 is http://dev.openttdcoop.org/issues/show/2685 "OpenGFX+ Industries - Code Review #2685: english.lng remarks - #openttdcoop Development Zone"
13:17:23  <planetmaker> ok, then we agree
13:22:55  <Brot6> OpenGFX+ Industries - Revision 119:6eb0183ff76b: Change: Better wording for the English language ... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-industries/repository/revisions/6eb0183ff76b
13:54:03  *** andythenorth has joined #openttdcoop.devzone
14:45:25  *** Webster has joined #openttdcoop.devzone
14:45:47  *** Brot6 has joined #openttdcoop.devzone
14:45:50  *** SmatZ has joined #openttdcoop.devzone
14:46:50  *** tneo has joined #openttdcoop.devzone
14:47:19  *** Ammler has joined #openttdcoop.devzone
14:47:50  *** Terkhen has joined #openttdcoop.devzone
14:48:20  *** V453000 has joined #openttdcoop.devzone
14:48:50  *** Yexo has joined #openttdcoop.devzone
14:49:13  *** XeryusTC has joined #openttdcoop.devzone
14:49:50  *** avdg has joined #openttdcoop.devzone
14:50:20  *** DJNekkid has joined #openttdcoop.devzone
14:50:40  *** planetmaker has joined #openttdcoop.devzone
14:51:29  *** andythenorth has quit IRC
15:38:22  *** andythenorth has joined #openttdcoop.devzone
15:46:37  *** andythenorth has quit IRC
16:33:14  *** andythenorth has joined #openttdcoop.devzone
17:18:47  <Brot6> ogfx-industries: update from r116 to r119 done - http://bundles.openttdcoop.org/ogfx-industries/nightlies/r119
17:18:57  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r39), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r93), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r141), comic-houses (r71), firs (r1996), fish (r653), frenchtowns (r6), german-townnames (r34), grfcodec (r830), grfpack (r279), heqs
17:18:57  <Brot6> (r605), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (ERROR r293), nml (r1371), nutracks (r201), ogfx-landscape (r69), ogfx-rv (r107), ogfx-trains (r241), ogfx-trees (r49), opengfx (r673), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15), ttdviewer
17:18:59  <Brot6> (r34), ttrs (r36), worldairlinersset (r672)
17:19:34  <Brot6> newgrf_makefile: compile of r293 still failed (#2656) - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/ERROR/r293
17:20:08  <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66
17:20:56  <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666
17:24:39  <Alberth> Brot6: you're complaints are really weird
17:24:39  <Brot6> good afternoon, Alberth
17:25:14  <planetmaker> :-P
17:27:32  <Alberth> WARNING: '/usr/lib/rpm/brp-desktop.data/suse-screensavers.menu' does not exist <-- yeah, that seems to belong in a newgrf makefile project :p
17:27:53  <planetmaker> :-)
17:28:02  <Terkhen> :D
17:28:07  <planetmaker> newgrf-screens(h)aver
17:28:46  <Alberth> that's a openttd --root-window  for :p
17:49:30  *** ODM has quit IRC
18:21:56  <planetmaker> omg omg... I'm talking with George... I start to understand how his grf process works. It's sophisticated, yes. A combination of windows bat and perl. And recreating pcx and nfo files from code snippets and psds, renumbering everything, cutting it back into the (re-numbered) code snippets and doing so increasing the a14 version by one; all scripted. For all his ECS grfs at once.
18:22:23  <planetmaker> but any history is inevitably lost with every run of the scripts
18:22:32  <andythenorth> interestink
18:22:33  <planetmaker> everything is re-created from grfcodec -d
18:23:13  <Terkhen> wow
18:23:30  <Terkhen> so no comments at all? :O
18:23:51  <frosch123> he has lots of action c comments
18:24:49  <andythenorth> planetmaker: offer to convert it to nml :P
18:24:59  <Terkhen> oh, I did not know action C :)
18:25:08  <Terkhen> makes sense in this context
18:26:31  <planetmaker> give me an argument: using grfcoded -d and nforenum to beautify the code saves work and time as he then doesn't have to write structured code initially. What shall I reply?
18:27:14  <Rubidium> in Russia binary builts source?
18:27:34  <Terkhen> :D
18:28:56  <Alberth> symbolic names for constants don't work
19:51:28  *** Alberth has left #openttdcoop.devzone
20:01:51  <andythenorth> any comments / additions on newgrf stuff I posted?
20:01:54  <andythenorth> http://wiki.openttd.org/NewGRF_Recommended_Standards
20:03:17  <planetmaker> I'd not go as far as recommend the build system here. Maybe like "If unsure, consider using the newgrf build system from the openttdcoop DevZone..."
20:03:45  <andythenorth> personally I'd recommend it more strongly than that
20:03:56  <andythenorth> might be hard for you to advocate your own work :)
20:04:00  <andythenorth> perhaps
20:04:03  <planetmaker> well, _I_ don't mind.
20:04:11  <planetmaker> And _I_ would do that, too
20:04:29  <andythenorth> maybe I just improve the wording
20:04:38  <andythenorth> the wording throughout is unedited
20:04:43  <planetmaker> But I'm not sure whether it's the proper advice and to (implicitly) tell that people like George and Pikka to it wrong [TM]
20:05:00  <planetmaker> s/to it/do it/
20:05:01  <andythenorth> it's more like "if you don't have your own build system, this one could help you"
20:05:14  <planetmaker> that's what I tried to say, yes
20:05:22  <Terkhen> I agree with planetmaker, and I like that new wording :)
20:05:52  <planetmaker> maybe "If unsure how to compile and manage your newgrf..."
20:06:15  <andythenorth> changed
20:06:27  <andythenorth> not quite what you suggested - missed that while editing
20:07:08  <andythenorth> but close enough
20:07:15  <andythenorth> the page needs formatting and such
20:07:26  <andythenorth> and instructions without examples are worth not much
20:10:07  <planetmaker> I itemized it
20:11:31  <andythenorth> awesome
20:11:37  <andythenorth> we should break it into logical sections?
20:11:45  <planetmaker> yup
20:11:59  <planetmaker> my logical section might become soon my bed, though
20:12:39  <Terkhen> I can't think of a good reason to change GrfID with action14
20:12:46  <andythenorth> me neither
20:12:59  <planetmaker> woot? where did that thought come from?
20:13:11  <Rubidium> splitting up a NewGRF because it gets too many sprites for TTDP to handle?
20:13:12  <andythenorth> it's a question I left in caps ;)
20:13:20  <andythenorth> hmm
20:13:34  * andythenorth has tunnel vision 
20:13:40  <andythenorth> I only think about openttd
20:14:14  <planetmaker> Rubidium: as long as that suggestion is not implemented or asked for by ttdpatch users...
20:35:27  <andythenorth> changing grfid might be valid if both stable and beta versions of a grf are on bananas?
20:36:34  <frosch123> changing grfid makes only sense if the grf is totally different
20:37:14  <frosch123> you cannot replace a grf with some id with a grf with another id in a save
20:37:21  <frosch123> everything is assigned to that specific grfid
20:37:49  <frosch123> also you can upload different versions of a grf to bananas, and make newer ones only available in nightlies
20:38:00  <andythenorth> so there is a valid case for it?
20:38:04  <frosch123> though bananas does not quite support branches and maintaining releases :)
20:38:38  <frosch123> different grfids make only sense for stuff you can load both in one game
20:38:52  <frosch123> well, or for stuff that does not support action14
20:38:56  <andythenorth> so there is no sane case for different grfid
20:39:32  <frosch123> changing grfid is like renaming the project
20:41:02  <frosch123> e.g. when someone searches a specific grf, he might search for a specific grfid, and the pick the newest version of it
20:41:24  <andythenorth> frosch123: so wrt this page? http://wiki.openttd.org/NewGRF_Recommended_Standards
20:41:28  <andythenorth> what should I say?
20:42:18  <frosch123> also the add-newgrf window shows only the newest version of a grf
20:43:19  <frosch123> andythenorth: just say, the grfid identifies the product, not the version
20:43:23  <Brot6> NewGRF Meta Language - Revision 1372:c7d59ce6bf9b: Doc: Improve documentation of the engine_overr... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c7d59ce6bf9b
20:43:23  <Brot6> NewGRF Meta Language - Revision 1373:f5c4560bdeac: Add #2332: Regression test for engine override. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f5c4560bdeac
20:46:53  <frosch123> night
20:46:57  *** frosch123 has quit IRC
20:49:34  <Hirundo> Yexo: engine_override() is quite confusing, it's either engine_override(target) or engine_override(source, target), it seems
20:49:58  <Hirundo> so the optional parameter is the first one
20:50:39  <Yexo> true
20:51:29  <Hirundo> I guess it's best not to change it right after 0.1.0, though
20:53:54  * Hirundo fixes docs instead
21:03:09  <Brot6> NewGRF Meta Language - Feature Request #2332 (Closed): Engine overrides (action0 feature 8 prop 11) (Hirundo) @ http://dev.openttdcoop.org/issues/2332#change-6791
21:03:10  <Brot6> NewGRF Meta Language - Revision 1374:f11d7dc8af6d: Fix #2332: Order of parameters of engine_overr... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f11d7dc8af6d
21:07:49  <Terkhen> it is possible for an industry tile to access its industry's persistent storage?
21:07:56  <andythenorth> yes iirc
21:07:57  <Yexo> yes
21:08:07  <andythenorth> related object
21:08:15  <Terkhen> ok, thanks :)
21:08:22  <andythenorth> gets more exciting if you gave towns registers
21:08:29  <Yexo> use LOAD_PERM like for industries, just PARENT instead of SELF as scope
21:08:31  <andythenorth> then can a tile access the industries related object?
21:08:43  <Terkhen> andythenorth: that's exactly what I'm trying to do
21:09:00  <andythenorth> you need equivalent of parent().parent()
21:09:16  <Terkhen> I was checking the existing code and jumping to the wrong conclusion as I saw no way to get the parent's persistent storage
21:09:22  <Hirundo> that's not trivial, but can be done using industries persistent storage I think
21:09:23  <Terkhen> if it is possible then there must be a way
21:09:32  <Terkhen> I'll keep checking the code :P
21:09:42  * andythenorth -> bed
21:09:45  <andythenorth> good night
21:09:47  <Terkhen> good night andythenorth :)
21:09:47  <Hirundo> let industry store town info in its registers, industry tiles read it from there
21:09:49  *** andythenorth has quit IRC
21:09:54  <Hirundo> goodnight ... nvm
21:11:01  <Terkhen> yes, that route should be enough... industry tiles will probably not be checking town info very frequently
21:12:22  <Hirundo> what info do you need?
21:13:13  <Terkhen> nothing really, I was asking because I needed to know if the parent's storage can be accessed... I'm trying to implement town persistent storage but the code is quite confusing
21:13:26  <Terkhen> I was starting to think that it was not possible, but that was stupid :)
21:47:41  <Terkhen> my head hurts, but I think that I know how to do it now :)
21:47:43  <Terkhen> time for bed

Powered by YARRSTE version: svn-trunk