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