Times are UTC Toggle Colours
00:21:16 *** KenjiE20 has quit IRC 01:50:47 *** Seberoth has quit IRC 05:21:53 *** Guest658 has joined #openttdcoop.devzone 05:22:14 *** Guest658 is now known as planetmaker 06:12:18 <Brot6> FIRS Industry Replacement Set - Feature #1254 (New): All snowline code should not assume Arctic c... (andythenorth) @ http://dev.openttdcoop.org/issues/1254 06:22:58 <Brot6> FIRS Industry Replacement Set - Feature #1254: All snowline code should not assume Arctic climate (planetmaker) @ http://dev.openttdcoop.org/issues/1254#change-3182 06:35:24 <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (2006TTD) @ http://dev.openttdcoop.org/issues/839#change-3183 06:37:28 <Brot6> OpenGFX - Feature #1255 (New): Gumdrops (2006TTD) @ http://dev.openttdcoop.org/issues/1255 06:37:28 <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (2006TTD) @ http://dev.openttdcoop.org/issues/839#change-3184 06:48:11 <Brot6> OpenGFX - Feature #1255: Gumdrops (planetmaker) @ http://dev.openttdcoop.org/issues/1255#change-3185 06:59:51 *** ODM has joined #openttdcoop.devzone 07:08:24 <Brot6> OpenGFX - Bug #683 (Closed): Blue eyes too blue (planetmaker) @ http://dev.openttdcoop.org/issues/683#change-3186 07:10:41 <Brot6> OpenGFX+ - Feature #957: forest (planetmaker) @ http://dev.openttdcoop.org/issues/957#change-3189 07:11:25 <Brot6> OpenGFX - Feature #662 (Resolved): Rework trains (planetmaker) @ http://dev.openttdcoop.org/issues/662#change-3191 07:14:07 <Brot6> OpenGFX+ - Feature #162 (New): OldGFX - GUI -> do we want that? (planetmaker) @ http://dev.openttdcoop.org/issues/162#change-3192 07:38:51 <ODM> opengfx and opengfx+? weird:P 07:40:26 *** frosch123 has joined #openttdcoop.devzone 07:56:09 <planetmaker> base set and extension :-) 07:56:31 <planetmaker> opengfx+ is unreleased, though 08:07:29 <Brot6> NFORenum - Revision 470:ca4cda99d996: Fix: support action2 objects variable 5F. (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/ca4cda99d996 09:29:36 <Ammler> planetmaker: why can't you close #662? 09:31:47 <planetmaker> the trains? There's a dependency I missed 09:36:11 <Brot6> #openttdcoop NewGRF package - Support #1156 (Closed): Update homepages (Ammler) @ http://dev.openttdcoop.org/issues/1156#change-3196 09:40:42 <Brot6> OpenGFX - Feature #903 (Closed): grfcodec -c (was missing(?) sprites) (Ammler) @ http://dev.openttdcoop.org/issues/903#change-3197 09:42:26 *** Seberoth has joined #openttdcoop.devzone 09:49:56 *** SmatZ- is now known as SmatZ 10:24:00 *** KenjiE20 has joined #openttdcoop.devzone 10:41:35 <Brot6> OpenGFX - Feature #1255: Gumdrops (Ammler) @ http://dev.openttdcoop.org/issues/1255#change-3198 10:42:15 <Ammler> autsch 10:42:16 <Ammler> sorry pm 10:42:25 <Ammler> why did you move the temperate in toyland topic? 10:43:20 <Brot6> OpenGFX - Feature #156: Temperate sprites for toyland (Ammler) @ http://dev.openttdcoop.org/issues/156#change-3199 10:44:04 <Ammler> next time, I should first check, when the version was changed last time :-) 10:44:17 <Ammler> but you changed it without any reason 10:45:12 <Ammler> I don't think, you need to postpond tickets from 0.4, which is a later version anyway 10:45:35 <Ammler> I would make more sense to move tickets from 0.3.0 to 0.4 10:46:30 <planetmaker> uh... I moved temperate in toyland? You mean the version? 10:46:59 <planetmaker> I changed it to 1.0 as it's a HUGE task to replace all things with toyland only stuff 10:47:19 <planetmaker> Waiting and that only needs doing by the time we call it 'done' 10:48:01 <planetmaker> it won't be done by 0.3 nor by 0.4 10:48:17 <Ammler> well, we also might never reach 1.0 :-) 10:48:23 <planetmaker> we will. 10:48:26 <Ammler> :-P 10:48:55 <Rubidium> if you do it within 6 years from 0.1.0 you'll be even faster than OpenTTD :) 10:48:56 <planetmaker> And I changed it exactly for that reason: it won't be done before 10:49:10 <planetmaker> at least I don't *think* so 10:49:11 <Rubidium> OpenSFX on the other hand... that might never reach 1.0.0 10:49:17 <planetmaker> yeah... :S 10:50:03 <Ammler> maybe we can ask Arcon to fix http://dev.openttdcoop.org/issues/906, as he visited the thread right now 10:50:09 <planetmaker> Ammler, besides: target version is in my eyes a 'solve latest by' 10:50:43 <Ammler> for me it is just something we can change everytime we feel :-) 10:50:51 <planetmaker> which is pretty stupid 10:51:04 <planetmaker> then we don't need to set it at all when we constantly move it upwards 10:51:17 <Ammler> like if we now like to release 0.3.0, we can just move the pending tickets to 0.4 10:51:18 <planetmaker> and that's why I marked it 1.0 10:51:26 <planetmaker> which is stupid 10:51:31 <Ammler> true 10:51:39 <planetmaker> Then we should move all those things to 1.0 which we don't plan to do by 0.3 10:51:47 <planetmaker> Because they *have* to be done by 1.0. 10:51:55 <planetmaker> And *can* be resolved any release earlier 10:52:06 <Ammler> no, we can move that, when we like to release something but those aren't fixeable 10:52:10 <Ammler> like we did until now 10:52:21 <Ammler> but I see no reason to move things from 0.4 10:52:35 * Rubidium wonders why "we" never had such a debate :) 10:52:37 <Ammler> as that version isn't even started 10:52:40 <planetmaker> The target version is not a 'like to' but IMHO a 'must to' 10:52:58 <planetmaker> Ammler, then, there should be no version 10:53:04 <Ammler> Rubidium: because you have only _one_ manager :-) 10:53:08 <planetmaker> if it is a 'move to whenever desired' 10:53:57 <Rubidium> maybe it's because we don't give everything a due version :) 10:54:02 <planetmaker> ^ 10:54:35 <Ammler> not giving a due version is the same like giving one but move around like the feeling 10:54:49 <planetmaker> but the latter is stupid 10:54:58 <planetmaker> creating useless spam 10:55:29 <Ammler> well, as said, I didn't check, that you just moved it 10:55:35 <Ammler> else I wouldn't have done it 10:55:42 <Rubidium> just declare 1 bug for 1.0.0: no more issues (implicitly depending on all other issues) 10:56:15 <Ammler> that is why I said "autsch" :-) 10:56:27 <planetmaker> Ammler, yes, I know :-) 10:56:35 <Ammler> that was to me :-P 10:56:57 <planetmaker> My argument was rather against the incentive to mark issues as 'next' or '2nd next' release when there's no-one working on it and no end-of-task even visible 10:57:28 <Ammler> well, 2006TTD is obviously working on the fix temperate in toyland sprites 10:57:29 <planetmaker> especially that big tasks which will probably be there in another 12 months 10:57:41 <planetmaker> yes. But it's a BIG task 10:57:58 <planetmaker> he needs to re-do all stations / airports / bus stops / truck stops / docks 10:58:34 <planetmaker> Vehicles might need re-touch, too 10:58:54 <Ammler> target 1.0 is meant for stuff, which we even don't like to start, imo 10:59:14 <Ammler> but need to be done for it 11:00:00 <planetmaker> it's for all stuff which needs to be done but has no chance to be resolved by the next release 11:00:23 <planetmaker> Using 0.4 is completely useless ;-) 11:00:31 <Rubidium> ... unless someone puts really serious work into it 11:00:35 <Ammler> same with 1.0 :-P 11:00:38 <Ammler> in your view 11:00:58 <Ammler> 0.3 is next release, which is soon 11:01:04 <planetmaker> Ammler, no. 1.0 is the target revision when the bugs are fixed and all sprites there 11:01:16 <planetmaker> 1.0 is the vision 11:01:24 <Ammler> 0.4 is for things we are working but can't be finished to 0.3 11:01:27 <planetmaker> the minimum 11:01:34 <planetmaker> But no-one is working on the 0.4 things 11:01:36 <Ammler> 1.0 is for, yes we do, but we don't care 11:01:54 <Ammler> ...now 11:02:05 <planetmaker> *sigh* 11:02:13 <planetmaker> the point. So no-one knows when it will be done 11:02:46 <planetmaker> you know what: I delete 0.4 ;-) 11:02:56 <Ammler> then do the same with 1.0 :-P 11:03:18 <Ammler> I don't agree, but I also don't care ;-) 11:03:24 <Rubidium> suggestions: due date is when something *must* be done, i.e. roadmap-ish. If you don't think it'll make it put it in the "someone" state (i.e. 1.0) 11:03:45 <planetmaker> Rubidium, that's what I argue for. Yes. 11:03:50 <Ammler> really :-o 11:03:54 <Rubidium> if you don't feel it will be possible for 0.4, then don't say it should be done by 0.4. It'll only annoy users 11:04:00 <Rubidium> e.g. cargod*stt 11:04:07 <Rubidium> s/tt/t/ 11:04:18 <Ammler> well, the roadmap is for us 11:04:40 <Ammler> it is a kind of measure, if we are ready for a release 11:04:52 <Ammler> it shouldn't be viewed as a "order" 11:04:54 <planetmaker> Ammler, we always have a measure for the next release 11:05:04 <planetmaker> and that's the important one 11:05:05 <Rubidium> whether your ready to release shouldn't depend on whether some features are implemented or not 11:05:26 <Ammler> yep, then we can simply move those tickets to the next version 11:05:36 <Rubidium> it should depend on things like open bugs (not feature requests) 11:05:49 <planetmaker> hm, yup 11:05:52 <Ammler> well, we have closed bugs, but we don't release 11:06:13 <Ammler> :'-( 11:06:13 <planetmaker> The question for some things, though, Rubidium is: there are 'features' which just are essential 11:06:28 <planetmaker> at least for 1.0 11:06:41 <Rubidium> as such feature requests have no due date, although you could add a pseudo due date for features that really need to be done for the 1.0 11:06:41 <planetmaker> But then... that's what we have the minor versions for, I guess 11:06:54 <Ammler> planetmaker: any example? 11:07:09 <planetmaker> Ammler, like the hay bales. They IMHO need to be done by 1.0 11:07:16 <planetmaker> But they're no bug 11:07:41 <Ammler> we have luck, that ogfx doesn't get new features 11:07:42 <planetmaker> Contrary the poor building stage for the bubble generator can be considered a bug. As such a show-stopper for 0.3 11:08:29 <Ammler> IMO, the missalignment of "my" houses could be a reason for a release 11:08:42 <planetmaker> yes 11:08:57 <planetmaker> But before we release there are some things we can still fix 11:09:05 <planetmaker> And those are the maglev track sprites (provided) 11:09:06 <Ammler> I am quite suprised about the few feedback about 11:09:08 <planetmaker> And the bubble generator 11:09:20 <planetmaker> I guess VERY FEW use the opengfx nightlies 11:09:30 <Ammler> no, that bug is in the release 11:09:36 <Ammler> that is why I would like one 11:09:42 <planetmaker> exactly. But you fixed it 11:10:02 <Ammler> it isn't that obvious there, because that didn't use -c 11:10:08 <planetmaker> Also, the Fizzy drink factory has new sprites. That can be in 0.3, too 11:10:21 <planetmaker> Same with signals. That's important 11:10:45 <planetmaker> ground tile toyland. That should not be a 0.3 show-stopper. So the 0.3 is out-of-place IMHO 11:10:58 <Ammler> yeah, signals I would like to make today, if nobody else does 11:10:59 <planetmaker> as there's concensus to not change it to the sprites provided 11:11:07 <planetmaker> Please do; I miss the time 11:11:44 <Ammler> I will template it like a combination of Acorn and 2006TTD 11:11:45 <planetmaker> I'm not sure how much the offcie building improvement is done #883 11:11:54 <planetmaker> 0.3 or not? 11:12:02 <planetmaker> If it's not done yet: then not 0.3 11:12:11 <Ammler> well, I should explain there what he did wrong 11:12:14 <planetmaker> same with fences on airports. There's little to do about it. 11:12:30 <planetmaker> Is it just that he didn't use the template as you like? 11:12:40 <planetmaker> Or what was that? 11:12:53 <Ammler> the house templates can quite well be used for flat tiles too 11:13:01 <planetmaker> yes. But you have the sprites 11:13:04 <Rubidium> anyhow, in my opinion, for each (major) release you should spend some work on fixing all bugs, i.e. put adding "features" on the back burner 11:13:16 <planetmaker> Rubidium, yes 11:13:32 <Ammler> Rubidium: there are 2 different bugs in ogfx 11:13:41 <Ammler> some we simply can't fix 11:13:55 <Rubidium> like? 11:14:00 <Ammler> graphics things 11:14:34 <Ammler> I can fix alingment bugs 11:14:51 <Rubidium> so you need some resident graphics guy in your team :) 11:15:00 <planetmaker> yes :-( 11:15:04 <Ammler> [13:14] <darix> Ammler: JFYI: the problems with the 11.2 and 11.1 "can not find key" should be fixed. 11:15:19 <Ammler> foobar was one 11:15:25 <Ammler> s/was/is/ 11:15:38 <planetmaker> we should re-activate DanMacK :-) 11:15:51 <Ammler> on the other side, there aren't graphics bugs 11:15:56 <Ammler> only glithces 11:16:06 <planetmaker> which still needs a graphics artist 11:16:12 <planetmaker> there's no difference. 11:16:17 <Ammler> yes, but which don't stop a release 11:16:21 <planetmaker> Glitches just might need more patience than most devote 11:17:12 <planetmaker> http://dev.openttdcoop.org/issues/781 <-- and it's a bit frustrating when there's not really much quality feedback 11:17:20 <planetmaker> though I guess that issue can be closed... 11:24:06 <Ammler> yeah, that is a VERY silly thing 11:25:18 <planetmaker> what is veryy silly? That issue? 11:25:24 <planetmaker> Not really... 11:25:56 <Ammler> well, then answer my question :-P 11:26:39 <andythenorth> DanMacK is pretty busy with other stuff :) 11:27:12 <planetmaker> he's always pretty busy with other stuff 11:27:28 <planetmaker> despite he offered his drawing help 11:27:48 <planetmaker> Ammler, and you question is? 11:28:03 <Ammler> the last note there 11:28:30 <planetmaker> I've no idea 11:28:39 <planetmaker> Quality feed back would also involve an answer to that ;-) 11:29:05 <Ammler> yeah, but that makes it silly, imo, the bug not the lack of the feedback 11:29:49 <Ammler> well, the same is with my house realignment 11:30:06 <Ammler> as I made the bulk fix 11:30:30 <Ammler> I didn't respect odd bounding boxes 11:30:54 <Ammler> but it needed almost 4 months until someone reported it 11:32:06 <Ammler> before that, I would have made a bet, that the alignment is perfect :-( 11:38:14 <planetmaker> well. We cannot be perfect. 11:38:18 <planetmaker> We can only fix what we know 11:38:28 <planetmaker> It's the same here in OpenGFX like it is with OpenTTD 11:38:38 <planetmaker> People have to report bugs. We cannot see everything ourselves 11:41:26 <Brot6> Autopilot - Feature #1251 (Closed): convert to hg (Ammler) @ http://dev.openttdcoop.org/issues/1251 11:41:26 <Brot6> Autopilot - Feature #1251 (Closed): convert to hg (Ammler) @ http://dev.openttdcoop.org/issues/1251#change-3200 11:42:30 <Brot6> #openttdcoop - Support #144 (Closed): Tag will automatically create a release bundle (Ammler) @ http://dev.openttdcoop.org/issues/144#change-3201 11:42:30 <Brot6> #openttdcoop - Feature #182 (Rejected): Replace RSS Feed with hooks... (Ammler) @ http://dev.openttdcoop.org/issues/182#change-3202 11:53:54 <Ammler> Removed Category OpenGFX+ from OpenGFX 11:54:10 <Brot6> OpenGFX - Feature #595 (Closed): spin-off newgrfs (Ammler) @ http://dev.openttdcoop.org/issues/595#change-3203 11:58:23 <Brot6> OpenGFX - Feature #1200 (Feedback): NoGFX for dedicated (Ammler) @ http://dev.openttdcoop.org/issues/1200#change-3204 12:04:53 <Brot6> OpenGFX - Bug #1073 (Confirmed): medium font sprites too high (with accents) (Ammler) @ http://dev.openttdcoop.org/issues/1073#change-3205 12:07:43 <Brot6> OpenGFX - Feature #986: more snow sprites / smoother transition (Ammler) @ http://dev.openttdcoop.org/issues/986#change-3206 12:24:20 <Ammler> does railtypes btw. allow different signals? 12:29:56 <planetmaker> no 12:30:41 <Brot6> FIRS Industry Replacement Set - Bug #898: Bank appearing in Towns/Cities and accepting Sand (foobar) @ http://dev.openttdcoop.org/issues/898#change-3207 12:33:39 <Brot6> FIRS Industry Replacement Set - Feature #471: Blacksmith graphics (foobar) @ http://dev.openttdcoop.org/issues/471#change-3208 12:33:40 <Brot6> FIRS Industry Replacement Set - Bug #898: Bank appearing in Towns/Cities and accepting Sand (planetmaker) @ http://dev.openttdcoop.org/issues/898#change-3209 12:35:55 <Brot6> FIRS Industry Replacement Set - Feature #476: Windmill graphics (foobar) @ http://dev.openttdcoop.org/issues/476#change-3210 12:35:55 <Brot6> FIRS Industry Replacement Set - Feature #470 (Rejected): Vehicle Plant (foobar) @ http://dev.openttdcoop.org/issues/470#change-3212 12:36:46 <Brot6> FIRS Industry Replacement Set - Feature #472 (Rejected): Resort Hotel (foobar) @ http://dev.openttdcoop.org/issues/472#change-3213 12:37:35 *** FooBar has joined #openttdcoop.devzone 12:38:58 <Brot6> FIRS Industry Replacement Set - Feature #467 (Rejected): Fish Farm (foobar) @ http://dev.openttdcoop.org/issues/467#change-3214 12:42:41 <planetmaker> FooBar, you're fast resolving issues ;-) 12:42:52 <FooBar> I like those types of issues :) 12:42:57 <planetmaker> hehe 12:50:36 <Rubidium> do you have some method of donating to openttdcoop? So [hta]specx can put his positive issues somewhere as well? :) 12:51:25 <planetmaker> hm... I guess we should create a paypal account or so. 12:51:31 <planetmaker> we don't yet. 12:51:51 <planetmaker> Ammler, ^ or is there an easy to donate to account from the assoc? 12:52:17 <FooBar> probably the one who is actually paying for the server makes most sense to me for receiving the donations 12:52:42 <FooBar> otherwise you need to do even more bank transfers... 12:53:03 <planetmaker> that's either Ammler or me 12:53:46 <FooBar> well, either one of you two then :) 12:55:39 <FooBar> maybe also accept direct bank transfer; I believe that's free within Europe? 12:55:58 <FooBar> That way paypal doesn't get to keep the 4% they keep :) 12:56:15 <FooBar> I mean free within euro-countries 12:56:18 <Rubidium> FooBar: yeah... but only for EUR transfers 12:56:28 <FooBar> yes, that :) 12:57:24 <Rubidium> and you need all the info... IBAN and such, and that can be tricky to figure out... right, pm? 12:57:53 <planetmaker> oh yes :-) 12:57:56 <Rubidium> there's very little to find about the association itself though 12:58:09 <FooBar> last time I donated to orudge a reasonable amount got "lost in translation", both due to paypal commission and exchange rate; I didn't really like that 12:58:09 <Ammler> well, or we tell them, they sould donate some money to the homeless in the town or a church or something :-) 12:58:39 <planetmaker> woot, FooBar ? 12:58:50 <Ammler> I am also fine, if they donate to wwf or greenpeace 12:58:51 <planetmaker> Rubidium, yes, that's because the assoc is mostly dead 12:59:42 <Rubidium> Ammler: but donating to them is easy! 13:00:00 <Rubidium> they should donate to the Hiroshima peace fund (or whatever it's called these days) 13:00:50 <Ammler> planetmaker: wouldn't that be an idea, instead creating a donating page, we make a page and ask those people to donate to wwf or greenpeace in our name 13:01:16 <planetmaker> well... they could also donate to us ;-) And if we get too much we donate it for them ;-) 13:01:28 <planetmaker> or to orudge 13:01:42 <Ammler> orudge has already too much money 13:01:51 <planetmaker> has he? 13:02:01 <Ammler> well, as they said at the party 13:02:18 <planetmaker> Honestly, I don't mind, if people also donate to support the devzone... 13:02:32 <Ammler> me neither 13:02:47 <planetmaker> And if it's only so that I can donate more to... whatever, for example Welthungerhilfe like last Sunday 13:03:06 <Ammler> I prefer to help nature 13:03:16 <planetmaker> :-) 13:03:19 <Ammler> human help is something for the "big companies" 13:03:39 <planetmaker> See. Therefor it's good if people donate to the devzone. Then you can donate to nature, and I can donate to development aid ;-) 13:04:11 <planetmaker> (development aid is also natural protection work ;-) ) 13:04:24 <Ammler> IMO, it is stupid to buy cheap coffee and same time send money to that country so our dear Nestle can still make more money with cheap workers there 13:04:44 <planetmaker> that's not development aid ;-) 13:05:12 <Ammler> that is why I prefer sponsoring wwf and greenpeace :-) 13:05:14 <planetmaker> whatever. I think we indeed should start to supply a donation possibility 13:05:53 * planetmaker ponders 'private' or 'business' account with paypal 13:06:24 <Ammler> use "#openttdcoop association" if you need a name 13:06:30 <planetmaker> yeah 13:07:25 <Ammler> we should at least fake one meeting this year ;-) 13:07:32 <planetmaker> yep 13:07:52 <planetmaker> and change the constitution. To yearly or bi-yearly meetings 13:08:16 <KenjiE20> "I bring this meeting to order. Any items on the agenda? no? okay meeting adjurned" :p 13:08:33 <planetmaker> like that :-P 13:09:15 <Ammler> well, the assoc is reach, it has 100 CHF 13:09:22 <planetmaker> :-) 13:09:42 <planetmaker> which you all spent on booze! ;-) 13:09:56 <Ammler> which I then forgot 13:10:06 <Ammler> (to bring to the party) 13:11:15 <planetmaker> evil you! 13:11:19 * planetmaker hugs Ammler 13:11:58 <Ammler> well, I pay the first 2 months with it 13:13:26 <Ammler> and we have again CHF60 in the current adsense 13:15:50 <planetmaker> since then? 13:37:19 <Brot6> FIRS Industry Replacement Set - Revision 1194:0aa0e07b197f: Feature: Wholesale Market basic code ... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/0aa0e07b197f 13:39:48 <Brot6> FIRS Industry Replacement Set - Feature #462: Wholesale Market graphics (foobar) @ http://dev.openttdcoop.org/issues/462#change-3219 13:39:48 <Brot6> FIRS Industry Replacement Set - Feature #470: Vehicle Plant (andythenorth) @ http://dev.openttdcoop.org/issues/470#change-3220 13:40:36 <FooBar> andythenorth: then update your website so that it doesn't lead me to believe that you don't want it any more ;) 13:41:41 <andythenorth> FooBar: nah, that one's not deprecated :) 13:41:42 <andythenorth> http://tt-foundry.com/sets/FIRS/schema/industries?economy=everything#vehicle_plant 13:41:45 <Webster> Title: TT Foundry: Pixel Creations for OpenTTD (at tt-foundry.com) 13:42:00 <andythenorth> it would be good soon to talk about set / economy design 13:42:10 <andythenorth> I'd like to break the back of 0.4 first though 13:42:26 <andythenorth> It's going to be a big release, probably several hundred commits :) 13:42:27 * andythenorth afk 13:42:49 <FooBar> http://tt-foundry.com/sets/FIRS/schema/industries_coders doesn't agree... 13:42:51 <Webster> Title: TT Foundry: Pixel Creations for OpenTTD (at tt-foundry.com) 13:43:15 <andythenorth> FooBar: you're correct :o 13:44:08 <FooBar> but what is the advantage of the vehicle plant over the metal foundry? 13:44:18 <FooBar> metal foundry does the same, and more... 13:44:50 <FooBar> but I think most will just ship their steel to the machine shop... 13:47:22 <FooBar> also, I started adding the industry name to the top of it's pnfo file. Makes it easier to find where the industry starts if you have to read firs.nfo 13:47:33 <andythenorth> FooBar: good call 13:47:37 <FooBar> So if you could do the same as soon as you edit some industry... 13:47:48 <andythenorth> although really the make file should just insert it as a comment :) 13:48:07 <andythenorth> FooBar: I'm at work now, but can talk later 13:48:22 <FooBar> ok cool 13:48:23 <andythenorth> (advantage of vehicle plant comes if we add 'cars' as an economy specific cargo) 13:48:25 <andythenorth> cheers 14:26:25 <planetmaker> andythenorth, so... did you give that patch I gave you to that end a try? 14:26:38 <planetmaker> that end = insert file as comment? 14:27:18 <planetmaker> in any case I did not receive any feedback, even though I provided it to you as fast as I could write, just an hour after you asked / proposed it 14:28:46 <Ammler> planetmaker: nml does produce nfo, so it would be possible to nml already partially 14:29:02 <Ammler> I.e making a uk signals newgrf with nml 14:29:09 <Ammler> and then using the nfo for the extra grf 14:29:27 <Ammler> to use* 14:29:28 <planetmaker> yes. But keep NML out of OpenGFX sources so far 14:30:27 <planetmaker> e.g. I don't want yet NML source code in the repo 14:30:34 <planetmaker> s/e.g./i.e./ 14:31:19 <Ammler> well, you will need nml, if you like to change/fix the signals 14:31:28 <planetmaker> It's fine to use for any newgrf 14:31:40 <planetmaker> But it's not usable for the base sets. 14:31:55 <planetmaker> Because it would mean that no package maintainer can build OpenGFX anymore 14:32:37 <Ammler> hmm, we could make a subdir nml 14:32:42 <planetmaker> Please don't 14:32:54 <FooBar> you can add the nml source code, but just past the nfo output generated with it in the actual source that generates OpenGFX 14:33:10 <Ammler> yes, but where shall I add the nml source? 14:33:20 <FooBar> so basically something for the "source" folder: something that isn't used directly but that might be useful some time 14:33:36 <FooBar> so I suggest either in that folder or in a subfolder of that folder 14:33:52 <Ammler> sprites/nml 14:33:54 <planetmaker> subfolder of the generated (p)nfo 14:34:24 <planetmaker> hm... 14:34:45 <planetmaker> ok. sprites/nml 14:34:58 <Ammler> nml is required to make the signals 14:35:07 <Ammler> but it isn't required to build opengfx 14:35:19 <planetmaker> ? 14:35:30 <planetmaker> That doesn't sound sane 14:35:40 <FooBar> no, source/nml 14:35:46 <Ammler> the source is a png and nml 14:35:59 <Ammler> which then is used to make the pcx and nfo for opengfx 14:36:05 <planetmaker> Ammler, then you need means to convert png->pcx 14:36:08 <FooBar> hmmm...we don't have that in opengfx... 14:36:08 <planetmaker> do that by hand 14:36:10 <planetmaker> beforehand 14:36:20 <FooBar> sprites/source/nml 14:36:25 <planetmaker> nml does no graphics conversion 14:36:32 <Ammler> planetmaker: I do, but we should keep the nml somewhere 14:36:36 <planetmaker> FooBar, no, that is not a good folder 14:36:44 <Ammler> because the pcx isn't templatish 14:36:46 <Ammler> only the png is 14:37:00 <planetmaker> Ammler, just convert the png using gimp? 14:37:12 <planetmaker> or imagemagix? 14:37:32 <planetmaker> Don't start adding image conversion to the required scripts. That's hell a lot of deps I don't want 14:37:34 <FooBar> or just use nml to create the grf, decode it again and use that pcx and nfo for in opengfx 14:37:39 <Ammler> I don't 14:37:49 <planetmaker> FooBar, no. NML just is the means to generate the NFO 14:37:54 <Ammler> but if you decode the grf, you won't have nice sprites anymore 14:38:12 <planetmaker> at least in this case. 14:38:26 <Ammler> planetmaker: no, I don't use the nfo from nml 14:38:33 <Ammler> I generate the grf and decode 14:38:39 <planetmaker> what? 14:38:40 <Ammler> so I have nfo and pcx 14:38:41 <FooBar> well, it's basically how opengfx is created in the first place: from lots of decoded grf files 14:38:58 <planetmaker> Ammler, sorry, that is kinda insane 14:39:28 <planetmaker> Ammler, just convert the png to pcx. 14:39:33 <Ammler> then stay with nfo :-( 14:39:53 <planetmaker> Then use NML to write the NFO. There you can in NML use the nice templates you like 14:39:56 <Ammler> thought it is a good idea, as I like to make a newgrf too 14:40:30 <planetmaker> yes, still. Adding a de-coded newgrf is bollocks 14:40:46 <planetmaker> you have nicely templated sprites in png files, right? 14:40:48 <Ammler> hmm, we have that quite a lot 14:40:52 <planetmaker> Then convert those files to pcx 14:40:56 <planetmaker> Use those. 14:41:05 <Ammler> I don't code the same twice 14:41:31 <planetmaker> Then use NML to easily encode those files as sprites - and chose NFO output 14:41:42 <planetmaker> add that nfo as OpenGFX source 14:42:14 <Ammler> the advantage of nml is using png 14:42:18 <planetmaker> But don't screw up the templating in the graphics files by adding the files twice, once as png and then the same thing as a big monolithic, de-compiled pcx 14:42:40 <planetmaker> IF you want OpenGFX to use NML somewhen it's sane to do it properly now: 14:42:46 <planetmaker> Providing the graphics as PCX 14:42:52 <planetmaker> And have NML only write the used NFO 14:43:07 <planetmaker> But please, please don't just add de-compiled NFO 14:43:15 <planetmaker> That's plain ugly, unreadable and un-commented 14:43:30 <planetmaker> And the latter two points are a no-no for NEW code 14:43:38 <Ammler> well, I do it in nfo, but I don't agree :-P 14:43:41 <planetmaker> And OpenGFX _is_ still NFO 14:43:45 <planetmaker> *sigh* 14:43:49 <planetmaker> You don't get me, right? 14:43:56 <planetmaker> Neither my reasons nor the solution I propose? 14:44:16 <planetmaker> you seem to just have heart 'not NML' 14:44:41 <Ammler> having sources as nml is like having the photoshop as source for pcx 14:45:02 <planetmaker> you can do that. But add the NFO output from NML 14:45:07 <planetmaker> and NOT a de-compiled newgrf 14:45:14 <Ammler> what is the difference? 14:45:22 <planetmaker> the graphic file 14:45:33 <planetmaker> your way: png files + one ugly pcx 14:45:45 <Ammler> you need nml anyway 14:45:46 <planetmaker> my way: no png files, but several pcx 14:45:51 <Ammler> to make changes with the signals 14:46:34 <planetmaker> Ammler, that has to be untrue. OpenGFX must not depend upon NML 14:46:46 <planetmaker> It may be a help to coding parts, yes. 14:47:03 <planetmaker> But the result has to be NFO which is actually commited 14:47:12 <planetmaker> and the NFO should be commented. 14:47:28 <planetmaker> And it is only commented, if you chose NFO output. IIRC and I hope ;-) 14:47:36 <Ammler> no 14:47:48 <planetmaker> If it isn't, it's bad 14:47:49 <Ammler> the nml nfo is as "ugly" as the decoded maybe uglier 14:48:33 <Ammler> so either you code it in nfo or you would use nml as "base" 14:48:47 <Ammler> and if you have changes to that part, you need again nml 14:48:55 <Brot6> FIRS Industry Replacement Set - Revision 1195:6dfc222ec90b: Feature: Supermarket basic code and n... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/6dfc222ec90b 14:48:55 <Brot6> FIRS Industry Replacement Set - Feature #479: Supermarket graphics (foobar) @ http://dev.openttdcoop.org/issues/479#change-3221 14:49:05 <planetmaker> Ammler: you may use NML to make the sprite alignment easy by using NML templates. 14:49:09 <Ammler> like if you change a image, you need gimp 14:49:22 <planetmaker> But then please edit the resulting NFO by hand, so that it is commented 14:49:28 <planetmaker> NFO is our source here. Not NML 14:49:44 <planetmaker> So clean NFO is important. Still 14:50:17 <Ammler> so you think decoded nfo is not clean? 14:50:24 <planetmaker> It's not commented 14:50:32 <planetmaker> And I don't want one big image again 14:50:39 <planetmaker> with a random arrangement of signals in the pcx 14:50:47 <Ammler> why? 14:50:52 <Ammler> it isn't source 14:50:55 <planetmaker> Ugly? pcx is source 14:51:06 <Ammler> damn, it isn't that is the whole point 14:51:16 <planetmaker> Ammler, NML is no dependency 14:51:28 <Ammler> but gimp is? 14:51:31 <planetmaker> no 14:51:40 <Ammler> photoshop then? 14:51:56 <Ammler> :-) 14:51:58 <planetmaker> no particular 14:52:23 <planetmaker> you just propose to add ugly source code. Only so that you can write the source code in one particular way 14:52:27 <planetmaker> I find that not acceptable 14:52:54 <planetmaker> It's like providing patches to OpenTTD in word format 14:53:07 <Ammler> I do agree that nfo or pcx which you should be able to change should be nice source 14:53:21 <planetmaker> yes. 14:53:24 <Ammler> but in this case, that nfo and pcx would never be touched 14:53:38 <Ammler> only maybe regenerated 14:53:48 <planetmaker> Nope. Source is not generated. 14:53:55 <Ammler> it isn't source 14:54:04 <planetmaker> pcx+nfo = source of OpenGFX 14:54:14 <Ammler> oh well 14:54:45 <planetmaker> the photoshop files are also source as they might give an easier starting point to editing 14:54:58 <Ammler> like nml could :-( 14:54:58 <planetmaker> But in many cases the pcx have been touched separately. And after photoshopping 14:55:11 <planetmaker> So the pcx are the source and reference really 14:55:20 <planetmaker> They're authorative 14:55:35 <planetmaker> So what you can do is: generate your sprite alignment using NML 14:55:45 <planetmaker> But then the resulting NFO will need hand-editing with comments 14:55:54 <planetmaker> and the images of course have to be in pcx format 14:56:03 <Ammler> and you think, that is easier 14:56:08 <planetmaker> yes 14:56:10 <planetmaker> might be 14:56:12 <Ammler> aslo in respect of future changes 14:56:15 <planetmaker> yes 14:56:49 <Ammler> I change the nml and need again to edit the final nfo 14:56:58 <Ammler> that is bullshit sorry 14:57:12 <Ammler> either you use nml 14:57:12 <planetmaker> Yes, currently. But this is not an NML project 14:57:15 <Ammler> or you use nfo 14:57:26 <planetmaker> If you want it that way: use NFO 14:57:44 <planetmaker> If you already want to prepare for NML: then you currently have to do some extra work 14:57:48 <Ammler> you are really evil :-P 14:57:53 <Brot6> OpenGFX - Bug #657: Enable company colours for sweets factory (2006TTD) @ http://dev.openttdcoop.org/issues/657#change-3223 14:57:54 <planetmaker> Yes. 14:58:25 <planetmaker> But this is an NFO project. And NML does officially not exist and is no development tool for OpenGFX 14:58:40 <planetmaker> if it can become that, I'm the first to implement it. 14:58:49 <Ammler> yes, but gimp is 14:59:51 <Ammler> IMO, this should be a decision of those people working with it 15:00:00 <Ammler> why don't we need to care about others? 15:00:22 <Ammler> as long as we don't make it a building requirement? 15:01:08 <Ammler> -n't 15:01:25 <FooBar> according to GPL, source is "preferred form of editing". If using NML to create grf, then decoding that and copy/paste to OpenGFX, than that IMO is "preferred form of editing" 15:01:49 <Ammler> yes, the nml is in the source, 15:02:08 <Ammler> it is needed, if you like to change it later anyway 15:02:31 <Ammler> it is like openttd does have openttd.grf in the source 15:02:46 <FooBar> true, or you just tweak the pcx and nfo (well, if someone were to fork OpenGFX and wanted to change that particular part) 15:03:25 <FooBar> if you like to do it in pure NFO, than that is "preferred form of editing" also 15:03:46 <Ammler> yes, I do just not agree, that we need to be so strict 15:17:37 <Brot6> FIRS Industry Replacement Set - Revision 1196:f84f66dd7f77: Feature: Retail Market basic code and... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/f84f66dd7f77 15:17:37 <Brot6> FIRS Industry Replacement Set - Feature #477: Retail Market graphics (foobar) @ http://dev.openttdcoop.org/issues/477#change-3224 15:19:43 <Brot6> OpenGFX - Feature #839: 4737-4742: Fizzy drink factory (2006TTD) @ http://dev.openttdcoop.org/issues/839#change-3225 15:32:39 <Ammler> http://dev.openttdcoop.org/projects/opengfx/repository/entry/sprites/nfo/extra/extra-signals.pnfo <-- does already have british semaphores? 15:34:14 <Ammler> that file is cryptic 15:38:07 *** Seberoth has quit IRC 15:42:37 *** Seberoth has joined #openttdcoop.devzone 15:44:11 <FooBar> Ammler: yes we have, the same as in OpenTTD_extra (both types drawn by mb) 15:45:42 <Brot6> FIRS Industry Replacement Set - Revision 1197:326c09193489: Feature: Sugar Refinery basic code an... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/326c09193489 15:46:58 <Ammler> FooBar: but they aren't british, those are rightsided 15:47:14 <FooBar> ? 15:47:30 <FooBar> there's two types of semaphores, one with the arm on the left and one with the arm on the right 15:47:50 <Ammler> where are the others? 15:48:07 <Brot6> FIRS Industry Replacement Set - Feature #474: Sugar Refinery graphics (foobar) @ http://dev.openttdcoop.org/issues/474#change-3226 15:48:38 <FooBar> they should be in there somewhere, guarded with some action 7; the semaphores with arm on left show when drive side is set to left 15:48:53 <Ammler> hmm 15:49:31 <FooBar> I checked in the game, not in the source, so where they are in the source I don't know 15:49:40 <Ammler> you can have such ingame? 15:49:57 <Ammler> I guess, it matters how you start a game then? 15:50:48 <Ammler> I always thought, we will add the Born Acorn signals and not replace others 15:51:50 <FooBar> you need to change the drive side, but you can only do that before starting the game 15:52:08 <Ammler> I was able to change that after 15:52:11 <Ammler> :-o 15:52:31 <Ammler> I am still are 15:52:32 <FooBar> that's possible now? 15:52:32 <Brot6> FIRS Industry Replacement Set - Revision 1198:5af479cd7ddc: Fix (r1197): Sugar Refinery needn't b... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/5af479cd7ddc 15:52:36 <FooBar> hmmm 15:52:56 <Ammler> I wasn't, then I loaded the save and I am able to change 15:53:01 <FooBar> anyways, we might need to include some check with patch flag 3B 15:53:10 <FooBar> (if that isn't in there already) 15:53:21 <FooBar> that is the "signalsontrafficside" switch 15:53:51 <Ammler> are you really sure, there are both types already in the game? 15:54:11 <FooBar> I can see both types, so yes 15:54:43 <Ammler> hmm, true 15:54:52 <Ammler> but only, if I start a new game 15:55:00 <FooBar> possibly 15:55:01 <Ammler> else they just change the side but keep the same 15:55:23 <FooBar> I had to do that as well (otherwise I don't think extra grf is reloaded, as that is a requirement for the signals to change 15:55:37 <FooBar> ) 15:56:02 <FooBar> also there already is a signal on traffic side check in it 15:56:08 <FooBar> so that should be alright then 15:56:19 <Ammler> you can reapply newgrfs 15:56:23 <Ammler> to realod the extra grf 15:56:45 <FooBar> ok, haven't tried that 15:58:04 <FooBar> also I forgot what I was doing... 15:58:27 <Ammler> sorry :-P 15:58:41 <Ammler> something with FIRS : 15:58:53 <FooBar> I knew that :D 15:59:15 <Ammler> nobody uses FIRS, so rather code opengfx :-P 15:59:48 <FooBar> I use FIRS... 15:59:57 <FooBar> but then I use OpenGFX as well... 16:00:20 <FooBar> andy doesn't use OpenGFX, let him code FIRS then :P 16:00:29 <Brot6> FIRS Industry Replacement Set - Revision 1199:1b0e80f79be6: Fix (r1197): Sugar Refinery needn't h... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1b0e80f79be6 16:01:46 <Ammler> yeah, he hasn't something else to do anyway 16:03:35 <FooBar> no, only like three other sets 16:05:55 <FooBar> I only have like 6 sets I can work on :o 16:06:35 <FooBar> anyways, dinner :) 16:06:52 <Ammler> isn't left-right already supported by openttd 16:07:14 <Ammler> seems both types are in the openttd.grf too 16:08:34 <Ammler> so the needed reload is not because of Action7 16:13:30 <Ammler> you have clima switches there only 16:17:40 <Ammler> hmm, ogfx uses 2 red 1 green, original 1 red 2green 16:17:48 <Ammler> for presignals 16:20:22 <Brot6> firs: update from r1190 to r1199 done (12 errors) - http://bundles.openttdcoop.org/firs/nightlies/r1199 16:21:43 <Brot6> nforenum: update from r469 to r470 done - http://bundles.openttdcoop.org/nforenum/nightlies/r470 16:21:52 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (ERROR r580), 32bpp-extra (r38), airportsplus (r52), basecosts (r20), comic-houses (r71), fish (r386), grfcodec (r228), heqs (r371), metrotrackset (r54), newgrf_makefile (r127), nml (r670), nutracks (r93), ogfxplus (r41), opengfx (r482), openmsx (r97), opensfx (r97), snowlinemod (r15), swedishrails (r141), transrapidtrackset (r15), worldairlinersset (r659) 16:22:27 <Brot6> 2cctrainset: compile of r580 failed - http://bundles.openttdcoop.org/2cctrainset/nightlies/ERROR/r580 16:28:54 <planetmaker> FooBar, 'preferred form of editing' does also imply that there's a way to build the thing from that source 16:29:00 <planetmaker> NML does not provide that. 16:29:16 <planetmaker> If we now add NML, we can totally forget about getting this set into distros 16:29:20 <planetmaker> It breaks everything 16:29:39 <planetmaker> And no, we cannot have NML as a dependency 16:29:41 <planetmaker> Not yet 16:30:05 <planetmaker> So we need a way to get clean NFO code 16:30:19 <planetmaker> how you get *that*. That's up to the author's choice 16:30:32 <planetmaker> But de-compiled things declared as source: that's not 'preferred' 16:30:57 <planetmaker> That's like saying I write assembler programmes by writing it in C++ and then using a de-compiler 16:30:58 <FooBar> planetmaker: I guess you're right at that 16:31:03 <planetmaker> Certainly not 'preferred' 16:31:30 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 32bpp-extra (1 errors) (Diffsize: 13), airportsplus (Diffsize: 13), basecosts (Diffsize: 11), comic-houses (3 errors) (Diffsize: 13), firs (12 errors), fish (6 errors) (Diffsize: 13), heqs (Diffsize: 13), metrotrackset, newgrf_makefile, nutracks (13 errors), opengfx, snowlinemod (Diffsize: 13), transrapidtrackset (Diffsize: 11), worldairlinersset 16:31:30 <Brot6> (Diffsize: 13) 16:33:03 <FooBar> Ammler: I believe the semaphore stuff in opengfx is the exact same as the semaphore stuff in openttd.grf But there is action7 a little further down the file, from the top of my head around line 217 and then some other time later on for toyland 16:34:32 <Ammler> yes 16:34:43 <Ammler> that has nothing to do with left-right side traffic 16:34:46 <FooBar> As for light signals: it might be a good idea to keep the same standard as openttd.grf. That allows creating a more uniform manual while using both base sets for screenshots 16:40:32 <Ammler> well, I never really compared that 16:40:38 <Ammler> I guess, ti doesn't really matter 16:41:00 <Ammler> you say red or green, not 2green or 2red 16:41:13 <FooBar> true 16:41:46 <FooBar> it's mostly the stuff about PBS that is confusing; there's still a yellow light in the screenshot while both base sets don't have that any more 16:42:49 <FooBar> Also I don't think having exactly the same signal aspects is crucial. "similar" is good enough for me 16:44:24 <Ammler> well, we code the signals we have now and then will see after the release :-) 16:44:47 <FooBar> fine with me :) 16:45:38 <FooBar> maybe the manual should get a 'signal equivalency table', which also can include signals of different kinds of signal sets 16:45:43 <FooBar> I'm not making that though 16:46:22 <Ammler> the pbs semaphores are indeed bad in opengfx 16:46:42 <Ammler> :-D 16:48:49 <FooBar> maybe copy those from openttd.grf (again) 16:49:26 <FooBar> hmmm...those might already be the same... 16:53:54 <Ammler> yes, they are also bad in openttd.grf :-) 16:54:21 <Ammler> nobody uses semaphores so nobody might care 16:55:16 <Ammler> the only difference to the generic signals is a one pixel orange and green light 17:01:04 <FooBar> there's a hard-to-see diagonal stripe on the back as well 17:01:18 <FooBar> as you can read, I /do/ use semaphores 17:01:59 <Ammler> :-) 17:03:27 * FooBar thinks Andy didn't think r1200 was going to be this type of fix: 17:04:20 <Brot6> FIRS Industry Replacement Set - Revision 1200:c9b599d1ffc2: Fix: template_accept_only_action_23_A... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c9b599d1ffc2 17:20:30 <DJNekkid> anyone know what the most pressing nutracks-issue is? 17:26:07 <Brot6> Nutracks - Revision 94:9e6e1aa61dbd: Fix: Wrong text id# on a handfull of tracks (DJNekkid) @ http://dev.openttdcoop.org/projects/nutracks/repository/revisions/9e6e1aa61dbd 17:32:40 <FooBar> fixing whatever errors/warnings nforenum spits... or did r94 fix that all? 17:34:01 <Ammler> after you removed all //@@DISABLE 17:35:09 <FooBar> you're allowed to disable warning 100, but none other than that, as I didn't have to in metrotracks either :P 17:36:59 <Brot6> FIRS Industry Replacement Set - Revision 1201:52523f311c21: Feature: Cane Plantation basic code a... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/52523f311c21 17:37:00 *** Alberth has joined #openttdcoop.devzone 17:38:45 <Brot6> FIRS Industry Replacement Set - Feature #460: Cane Plantation graphics (foobar) @ http://dev.openttdcoop.org/issues/460#change-3227 17:46:23 <DJNekkid> what about 144? (color codes in action8) 17:50:25 <FooBar> upgrade your renum ;) 17:52:03 <FooBar> http://www.openttd.org/en/download-nforenum-nightly 17:52:05 <DJNekkid> apparently all warnings were //'ed :) 17:52:11 <DJNekkid> just me not realizing it :) 17:58:13 <Brot6> FIRS Industry Replacement Set - Feature #1256 (New): Add more layouts to Cane Plantation (foobar) @ http://dev.openttdcoop.org/issues/1256 18:04:23 <Brot6> FIRS Industry Replacement Set - Revision 1202:4610632c3f72: Feature: Arable Farm now produces Sug... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/4610632c3f72 18:04:23 <Brot6> FIRS Industry Replacement Set - Feature #1257 (New): sugar cane should be called sugar beet in cl... (foobar) @ http://dev.openttdcoop.org/issues/1257 18:04:23 <Brot6> FIRS Industry Replacement Set - Feature #913 (Closed): Arable farm should also produce Sugar Beet... (foobar) @ http://dev.openttdcoop.org/issues/913#change-3230 18:04:36 <Ammler> grfcodec is so slow 18:18:05 <Ammler> the ingame sprite aligner still rocks :-) 18:18:28 <Ammler> would be nice to have a display for the sprite sizes 18:20:20 <Ammler> the offset I use has no logic, is that good? 18:28:28 <andythenorth> hi hi 18:30:22 <Rubidium> Ammler: maybe -O3 in your local flags might help? 18:30:45 <FooBar> hi andythenorth 18:31:04 <Ammler> Rubidium: it just seems slow, when you recode many times 18:31:16 <Ammler> and the base grf is big 18:31:48 <FooBar> andythenorth, I'm not so sure about the cane plantation if also the arable farm produces cane; both are basically the same thing 18:32:42 * andythenorth typing left handed, baby sleeping on right arm :P 18:32:57 <FooBar> :) 18:33:25 <Alberth> that's better than a sleeping right arm :) 18:33:31 <FooBar> :D 18:34:32 <FooBar> beware that one might result in the other 18:35:36 <andythenorth> FooBar: yup cane plantation might br 18:35:42 <andythenorth> be rednundant 18:35:53 <Brot6> OpenGFX - Revision 483:bd557a1795a7: Feature #840, #280: template for signals (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/bd557a1795a7 18:36:28 <FooBar> if so, then I'm not trying to guard it form other climates and such until we're certain 18:36:45 <andythenorth> I think we do without it 18:37:25 <FooBar> better leave it in some time, as introducing it and removing it 2 revisions later is a bit weird :P 18:37:31 <andythenorth> I want to avoid climate specific stuff mostly 18:37:59 <andythenorth> sugar cane / sugar beet is a valid climate specific thing 18:38:30 <andythenorth> I wonder what to do with cotton... 18:39:11 <andythenorth> lets revisit import/export cargos... 18:39:18 <Brot6> FIRS Industry Replacement Set - Feature #1258 (New): reconsider cane plantation (foobar) @ http://dev.openttdcoop.org/issues/1258 18:39:37 <andythenorth> what do we think about cargos that go 'off map'? 18:39:38 <FooBar> IMO climate specific stuff should have an equivalent accepting and producing exactly the same in all climates. Just graphics/industry name (and possible other properties) can be different 18:40:52 <FooBar> I'm not sure about import/export 18:41:32 <andythenorth> it's not traditional TTD world 18:41:44 <andythenorth> no cargo off map is the tradition 18:41:44 <FooBar> that, and I'm not sure if it's good gameplay 18:42:02 <FooBar> it could work with limited cargo 18:42:20 <andythenorth> I've got some valid uses for t 18:42:34 <FooBar> e.g. importing things in temperate that are only available in FIRS-tropic 18:42:40 <andythenorth> yup 18:42:51 <andythenorth> I want to do a UK Economy 18:42:54 <FooBar> that both introduces and again limits climate specific stuff 18:43:08 <andythenorth> it would need to import bauxite and cotton 18:44:18 <FooBar> let's look at primary cargos that are normally climate-specific 18:44:30 <FooBar> or maybe country-specific 18:44:34 <andythenorth> can you list... 18:44:42 <andythenorth> my typing is...impaired :P 18:44:52 <FooBar> :) 18:45:12 <FooBar> I'll just walk trough all primary cargo's and then you can go y or n ;) 18:45:22 <FooBar> or m for maybe 18:45:28 * Ammler definitly hates signals now 18:45:32 <FooBar> I'll add my opinion directly to it 18:45:35 <FooBar> coal m 18:46:00 <andythenorth> y is for specific? 18:46:20 <FooBar> y is for could be importable 18:46:42 <FooBar> I mean should me importable... 18:46:52 <FooBar> m is for /could/... 18:47:10 <FooBar> assuming we do some import feature 18:47:11 <andythenorth> coal m (tropic island...) 18:47:18 <FooBar> iron ore y 18:47:56 <andythenorth> y 18:48:06 <FooBar> bauxite y 18:48:15 <andythenorth> y 18:48:18 <FooBar> grain m 18:48:40 <FooBar> maybe even y 18:48:49 <andythenorth> y (export - canada) 18:48:57 <FooBar> ok, y it is 18:49:01 <FooBar> sugar cane y 18:49:25 <andythenorth> y 18:49:31 <andythenorth> hmmm 18:49:33 <andythenorth> n 18:49:50 <andythenorth> it's not shipped far in raw form 18:50:15 <FooBar> hmmm ok 18:50:21 <andythenorth> (grain terminals http://pcgladiator.blogspot.com/2009/03/thunder-bays-grain-terminals.html) 18:50:22 <Webster> Title: Manufactured landscapes: Thunder Bay's grain terminals (at pcgladiator.blogspot.com) 18:50:42 <FooBar> sand n 18:50:52 <andythenorth> n 18:51:00 <FooBar> gravel n 18:51:13 <andythenorth> n 18:51:15 <FooBar> fish y 18:51:20 <andythenorth> hmm 18:51:27 <andythenorth> dunno 18:51:35 <FooBar> m then :) 18:51:42 <FooBar> oil 18:51:46 <andythenorth> y 18:51:58 <FooBar> I meant "oil y" :P 18:52:23 <FooBar> I'm starting to realize that importing also could apply to secondary cargoes... 18:52:31 <FooBar> livestock n 18:52:34 <FooBar> milk n 18:52:44 <andythenorth> n n 18:52:58 <FooBar> fruit and veggies n 18:53:11 <andythenorth> n 18:53:26 <FooBar> food? :P 18:53:38 <andythenorth> not sure 18:53:48 <Ammler> I guess, it wasn't a good idea to start with semaphores 18:54:13 <FooBar> well, if all climates have livestock and fruit/vegetables, we shouln't be importing food: too easy 18:54:24 <FooBar> wood 18:54:30 <FooBar> m 18:54:45 <andythenorth> m 18:54:50 <FooBar> lumber 18:54:59 <FooBar> same as wood I guess 18:55:01 <andythenorth> m 18:55:11 <FooBar> chemicals 18:55:13 <FooBar> y 18:55:20 <andythenorth> y 18:55:25 <FooBar> fuel oil 18:55:26 <FooBar> y 18:55:29 <andythenorth> y 18:55:34 <FooBar> cotton y 18:55:36 <FooBar> wool y 18:55:57 <Ammler> oh sorry for disturbing your big voting round :-P 18:56:13 <FooBar> no problem, we're just ignoring you anyways at the moment :D 18:56:16 <andythenorth> i suppose for most of these a valid reason could be found for a certain economy 18:56:30 <FooBar> exactly 18:56:44 <FooBar> that makes it too difficult wrt industry ids and cargo ids I guess 18:57:00 <andythenorth> nah, just use the economy system 18:57:06 <andythenorth> it eill work fine 18:57:10 <andythenorth> will /s 18:57:30 <FooBar> it would need some dynamic allocation at least 18:57:38 <andythenorth> climate specific == bad, economy specific == good 18:57:56 <FooBar> that is a good conclusion 18:58:13 <andythenorth> exceptions are sugar cane / beet 18:58:26 <FooBar> that will be just a name change in tropic 18:58:54 <FooBar> maybe change the cargo RSGR as in "raw sugar" 18:59:03 <andythenorth> good idea 18:59:06 <andythenorth> i know how to handle cotton 18:59:24 <FooBar> should I guess or can you type? :P 18:59:51 <andythenorth> 1. don't feature it in 'basic' firs 19:00:23 <andythenorth> 2. make a cotton plantation in tropic, an import dock in other 19:00:24 <Brot6> OpenGFX - Revision 484:19c12959a990: Fix (rPREV): switch vertical signals (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/19c12959a990 19:00:26 <FooBar> I think the sheep farm should be a cotton farm in tropic and wool should be cotton in tropic and be done with that 19:00:33 <andythenorth> nah 19:00:39 <andythenorth> australia... 19:00:43 <FooBar> hmmm 19:01:11 <FooBar> import dock works for me as well 19:02:25 * FooBar ponders about a llama farm 19:02:32 <andythenorth> :D 19:02:54 <andythenorth> we could do a 'novelty' economy 19:02:57 <FooBar> to replace the sheep farm in tropic and produces whatever the sheep farm produces... 19:04:00 <FooBar> hmmm...llama are mainly pack and meat animal, while alpaca are mainly wool animal... 19:04:49 <andythenorth> ostrich? 19:04:59 <FooBar> new cargo: eggs 19:05:30 <FooBar> that in turn calls for a chicken farm... 19:06:17 <andythenorth> what unit ? 19:06:31 <FooBar> piece I guess... 19:06:44 <andythenorth> box? 19:07:25 <FooBar> probably 19:07:39 <FooBar> eggs are not shipped in bulk without any protection 19:09:45 <FooBar> anyways, I think import could work if amount of cargos are limited and that imported cargo cannot be exported 19:11:20 <andythenorth> yup 19:11:48 <andythenorth> and not in the default economies 19:12:39 <FooBar> agreed, only in specific economies where import actually adds to realisticness of gameplay 19:14:45 <andythenorth> warehouses or docks? or both? 19:16:05 <FooBar> maybe call it 'import terminal' and have different representations of it 19:16:56 <FooBar> but then warehouses always work, either next to docks or next to airport 19:17:15 <andythenorth> we could have d 19:17:26 <andythenorth> sprites that vary by coast 19:17:35 <andythenorth> so 19:17:39 <Brot6> OpenGFX - Revision 485:9900727c7fce: Feature #840: generic uk semaphores from Born Acorn (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/9900727c7fce 19:17:43 * andythenorth baby woke up 19:20:30 * andythenorth two hands 19:20:54 <Brot6> OpenGFX - Bug #280: standard signals (Ammler) @ http://dev.openttdcoop.org/issues/280#change-3232 19:21:13 <andythenorth> we could do an 'import terminal' that has a core set of buildings, and also shows other sprites depending on whether built on coast 19:21:57 <FooBar> that would be nice 19:22:08 <andythenorth> we could do varact 2 probability to make it prefer coasts 19:22:45 <FooBar> andythenorth: somebody pm'ed me to check this post, but I'm not sure of the answer... http://www.tt-forums.net/viewtopic.php?p=897012#p897012 19:22:47 <Webster> Title: Transport Tycoon Forums • View topic - FIRS Industry Replacement Set - v0.3 Officially Released (at www.tt-forums.net) 19:23:06 <andythenorth> FooBar: me neither :P 19:23:09 <andythenorth> I haven't tested it 19:23:17 <FooBar> ok, then I'll reply that :P 19:23:39 <andythenorth> code says 0 0 3 will allow closure of secondary industry 19:23:50 <andythenorth> primary industry shouldn't close because there's no production decreases 19:24:26 <andythenorth> secondary industry will close if no cargo for n months 19:27:01 <Ammler> so lame, he is reading the readme 19:27:14 <FooBar> :) 19:27:48 <FooBar> otherwise you could just say "what does the readme tell you" 19:28:01 <andythenorth> I think the reply would be "where's the fricking readme?" 19:28:07 <andythenorth> the readme concept is broken 19:28:40 <Ammler> wow, really fast industry 19:28:51 <Ammler> is that the speed of the smoke? 19:28:58 <andythenorth> what smoke :P 19:28:58 <FooBar> I think the name is the problem: people don't want to be pushed around with "read this, read that, read me" 19:29:13 <andythenorth> the issue is...where is the readme anyway? And how should I know to look for it? 19:29:26 <andythenorth> But I have moaned about this before :) 19:29:29 <FooBar> I don't know, there's no power station in firs... 19:29:47 <Ammler> http://bundles.openttdcoop.org/firs/releases/LATEST/readme.txt 19:30:10 <andythenorth> Ammler: I know :) 19:30:33 <Ammler> but this guy says, he read the readme 19:30:38 <andythenorth> ah 19:30:41 <andythenorth> well 19:31:21 <andythenorth> FooBar: we still have to reimplement all the default animations, and lots of new ones :P 19:31:39 <FooBar> I put that at "low priority" 19:32:15 <FooBar> for default industries, I think it's best to actually recode all layouts, as that also gives proper hooks for the varaction2 stuff we want to add 19:32:37 <Ammler> I don't see speed here 19:32:51 <andythenorth> FooBar: yes, that's going to be necessary 19:32:58 <andythenorth> Ammler: you have a newer build 19:33:04 <FooBar> old openttd has speed, new openttd has a date; maybe the wrong date, but a date ;) 19:33:36 <Ammler> why not disable firs on old builds? 19:33:45 <andythenorth> why bother? 19:33:49 <andythenorth> but we could 19:34:03 <Ammler> so wouldn't need to answer such questions :-) 19:34:17 <andythenorth> easily answered though 19:34:36 <andythenorth> the alternative is "why doesn't FIRS work on the 1.x releases?" 19:34:49 <Ammler> well, that would the firs tell you 19:34:55 <FooBar> it does work on 1.0.3... 19:35:09 <FooBar> the date stuff is backported 19:35:14 <Ammler> you can "customize" the message for ActionB 19:35:48 <FooBar> no need "requires OpenTTD 1.0.3/rxxxxx" would be good enough 19:35:55 <Ammler> yes 19:36:33 <FooBar> I don't know if there are other things in trunk that FIRS needs that are not in 1.0.3... 19:36:47 <FooBar> clustering is probably not critical if that isn't in 19:37:48 <FooBar> andythenorth: do you remember all things that were added to OpenTTD due to FIRS needing it? 19:38:59 <Ammler> get them to include custom fields 19:40:08 <Ammler> there is a simple reason, you should at least support all default industries too 19:40:21 <Ammler> just so someone can easy add the grf to a running game 19:40:50 <andythenorth> FooBar: I don't remember 19:40:57 <andythenorth> clustering uses a cb that fails safely 19:41:00 <andythenorth> or so I believe 19:41:29 <andythenorth> parameter settings gui fails safely 19:41:31 <Brot6> FIRS Industry Replacement Set - Feature #1257 (Closed): sugar cane should be called sugar beet in... (foobar) @ http://dev.openttdcoop.org/issues/1257 19:41:31 <Brot6> FIRS Industry Replacement Set - Revision 1203:0a83d2c9e446: Feature: rename sugar cane to sugar b... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/0a83d2c9e446 19:41:31 <Brot6> FIRS Industry Replacement Set - Feature #1257 (Closed): sugar cane should be called sugar beet in... (foobar) @ http://dev.openttdcoop.org/issues/1257#change-3233 19:41:44 <Ammler> hmm, seems not possible 19:41:44 <andythenorth> parameter settings gui is very nice, and frosch123 yexo etc should get cookies 19:41:56 <FooBar> darn, I just ate all cookies... 19:42:34 <Ammler> the whole newgrf debugging is also dedicated to any 19:42:37 <Ammler> andy* 19:42:46 <andythenorth> the debugging is awesome :D 19:43:00 <andythenorth> even reload_newgrfs is an epic win 19:43:11 <andythenorth> FooBar: - are you now familiar with the debug stuff? 19:43:11 <Ammler> rescan would be nice 19:43:16 <Ammler> and sprite sizes 19:43:25 <FooBar> andythenorth: I have it enabled but hardly ever look at it 19:43:49 <andythenorth> reload_newgrfs in console will save your sanity 19:44:01 <andythenorth> also if you do any layouts, the debug tool is invaluable 19:44:56 <andythenorth> FooBar: FIRS 0.4 is looking pretty chunky. 51 tickets 19:45:03 <andythenorth> I wondered about a smaller release then move to 0.5 19:45:23 <andythenorth> but grf ID will need bumping for 0.4, then maybe again for 0.5...might be unpopular :P 19:45:40 <Ammler> did ever someone complain about? 19:46:14 <FooBar> maybe do most code stuff in 0.4 and new layouts and graphics and things like that in 0.5 19:46:34 <FooBar> then even if you have to bump the grfid, there is no real need to upgrade running 0.4 games 19:46:41 <FooBar> just use 0.5 for new game 19:47:09 <andythenorth> Ammler: MB complained 19:47:23 <Ammler> really :-o 19:47:25 <Ammler> in your thread? 19:47:34 <FooBar> about that he cannot use FIRS in TTDPatch? 19:47:37 <andythenorth> in the DB set FIRS thread 19:47:42 <Ammler> ah 19:47:52 <Ammler> well, that is something else 19:48:11 <Ammler> he complained about that you changed the cargos (again) 19:48:31 <FooBar> I now changed it again... 19:48:36 <Ammler> we had so big fights with him so he makes a firs extension 19:48:49 <Ammler> IMO, YOU should make that extesnion 19:49:08 <FooBar> if only mb would open-source his code, that would be little effort 19:49:24 <Ammler> what you need his source for? 19:49:46 <FooBar> I don't fancy having to look up all vehicle IDs and basically redo what he did 19:50:00 <andythenorth> I've voted with my feet. I don't use DB set. 19:50:04 <andythenorth> is it good? 19:50:11 <Ammler> :-) 19:50:21 <FooBar> is it good he asks... :P 19:50:31 <andythenorth> it's the best? 19:50:38 <andythenorth> better than NARS 2? 19:50:40 <Ammler> until 2cc definitly 19:50:50 * Ammler doesn't like pikka sets 19:50:57 <Ammler> they are slow 19:51:07 <Ammler> too realistic 19:51:15 <FooBar> that I don't know, but it basically is to Germany-oriented countries what UKRS is to UK-oriented countries 19:51:33 <Ammler> well, "not like" i wrong 19:51:34 <andythenorth> I have a note here to tell grf authors about planned cargo changes / introductions where possible 19:51:38 <Ammler> is* 19:52:02 <Ammler> andythenorth: pikka sets are good for sp 19:52:03 <FooBar> andythenorth: tell them that SGCN is renamed to RSGR 19:52:15 <FooBar> that reminds me to update the newgrf wiki... 19:52:18 <Ammler> dbset and 2cc is best for MP 19:52:43 <Ammler> jpset is simply awesome 19:53:01 <andythenorth> FooBar: did you update the TTDP wiki? 19:53:06 <FooBar> I'm on it now 19:53:12 <andythenorth> I'll do my site now 19:53:29 <Ammler> you have too many sources for your infos :-) 19:54:00 <andythenorth> well...maybe 19:54:11 <andythenorth> it hasn't cause many problems so far though 19:54:16 <andythenorth> redmine is good for tickets 19:54:20 <andythenorth> my site is good for design 19:54:27 <andythenorth> everything else is just....everything else 19:54:32 <Ammler> :-) 19:55:10 <andythenorth> my site is a custom CMS which understands all the cargos / industries, otherwise I'd just use Redmine 20:08:03 <FooBar> hmmm...seems FIRS claims to be compatible with some ECS combinations... 20:08:43 <FooBar> shall we remove that and just deny all ECS compatibility? I haven't been paying attention to any kind of compatibility anyways... 20:08:54 <andythenorth> you wrote that code :) 20:09:09 <andythenorth> it's semi-compatible with ECS construction vector by Pikka 20:09:29 <andythenorth> for me it's "FIRS or nothing" 20:09:35 <andythenorth> except for add-ons 20:09:54 <FooBar> I know I wrote it... 20:10:01 <FooBar> let me unwrite it... 20:10:05 <FooBar> :D 20:10:15 <FooBar> what do you mean by semi-compatible? 20:10:23 <andythenorth> the claypit breaks 20:10:28 <andythenorth> and the brickworks 20:10:35 <andythenorth> so not very compatible :P 20:10:39 <FooBar> I'd call that incompatible :P 20:11:02 <FooBar> I'll keep the checks for na city set and canset in; those only need a specific parameter setting 20:15:16 <andythenorth> ok 20:40:22 * andythenorth ponders doing a ticket 20:42:23 <FooBar> do one 20:42:41 <Brot6> FIRS Industry Replacement Set - Bug #1242 (Closed): Farm snow check fails if tile is bulldozed (andythenorth) @ http://dev.openttdcoop.org/issues/1242#change-3234 20:42:50 <andythenorth> that one was already done :P 20:44:38 <FooBar> quick one, I like those :) 20:45:15 <andythenorth> FooBar: you can reuse your can plantation code for the cotton plantation 20:45:46 <FooBar> sure, I also reused it for the cane plantation which we probably end up removing 20:46:07 <andythenorth> that's what I meant :) 20:46:20 <andythenorth> your cane plantation can be the cotton plantation (for now) 20:46:24 <andythenorth> fields need to change 20:46:52 <andythenorth> blacksmith needs a 'don't build after xyz' date 20:48:03 <Brot6> FIRS Industry Replacement Set - Feature #1259 (New): Blacksmith needs a "don't build after xyz" date (andythenorth) @ http://dev.openttdcoop.org/issues/1259 20:49:19 <Brot6> FIRS Industry Replacement Set - Revision 1204:236ea733444e: Feature: FIRS now requires OpenTTD 1.... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/236ea733444e 20:50:30 <FooBar> andythenorth: did I ask to continue including all missing industries as part of http://dev.openttdcoop.org/issues/1171 or is that issue done now? 20:51:13 <andythenorth> FooBar: I think it's done 20:52:03 <FooBar> so we don't need all industries added for 0.4? 20:53:35 <andythenorth> nah not all 20:53:45 <FooBar> Also, we can switch back to bazaar now. The bug I filed 1.5 years ago is now fixed :P 20:53:53 <andythenorth> :) 20:54:14 <andythenorth> best to get 0.4 done and play some test games. I'm looking at the industry minimap now, it's quite a lot of industries :) 20:54:27 <FooBar> more than 40 now :o 20:54:28 <Ammler> FooBar: there is a Action7 with side 20:54:46 <FooBar> side? 20:55:04 <Ammler> -1 * 0 07 85 01 3B F2 //skip if signals not on traffic side 20:55:05 <Ammler> -1 * 0 07 86 01 04 F1 //skip if drive side not right 20:55:29 <FooBar> oh that, yes I tried to tell you before... 20:55:42 <Ammler> but I see not why 20:56:10 <FooBar> to differentiate between British and German signal style 20:56:23 <FooBar> I mean semaphore style 20:56:46 <Ammler> but the signals pcx from openttd.grf does also have 2 different styles 20:57:01 <Ammler> oh, maybe they do that also with Action7 20:57:07 <FooBar> British is always defined, and then IF signals on traffic side AND drive on right, they are redefined with German semaphore style 20:57:32 <Ammler> and why do you skip that for toyland? 20:57:50 <FooBar> openttd also uses action7, I copied the very code from openttdw.grf 20:58:08 <Ammler> there is no "w" anymore ;-) 20:58:15 <FooBar> back then there was ;) 20:58:19 <Ammler> :-) 20:58:35 <FooBar> the toyland skip I'm not sure... 20:59:54 <FooBar> maybe because toyland was sometime planned to have purple poles for all signals? 21:00:19 <Ammler> yes, you have extra toyland code there 21:00:21 *** Alberth has left #openttdcoop.devzone 21:01:20 <Ammler> I cut that off and make a special toyland nfo 21:01:22 <FooBar> I see, the extra toyland code is there because the toyland PBS signals are different 21:01:56 <FooBar> so there is no redundant code 21:02:09 <FooBar> but you can split if you like, that's no problem 21:03:55 <Brot6> FIRS Industry Replacement Set - Feature #1260 (New): Adjust various map colours (andythenorth) @ http://dev.openttdcoop.org/issues/1260 21:05:11 <Brot6> FIRS Industry Replacement Set - Feature #1171 (Closed): add missing industries as boxes (foobar) @ http://dev.openttdcoop.org/issues/1171#change-3235 21:05:23 <FooBar> andythenorth: I set windmill to blue because it's a blue box, but I agree that it isn't ideal 21:05:47 <andythenorth> makes sense, but I couldn't find one on the map :) 21:06:14 <FooBar> you can only see at closest zoom level (because it's 1-tile) and even then it's a bit tricky :P 21:06:28 <Ammler> I am quite suprised to find Action7 in the openttd.grf 21:06:35 <FooBar> while adding the industries, I noticed that there are too little colours :P 21:06:42 <andythenorth> yup 21:06:46 <Ammler> change to DOS :-P 21:06:56 <andythenorth> some ranges can't be used, clash with map / water / towns 21:07:10 <FooBar> ...too little /distinguishable/ colours ;) 21:07:38 <Ammler> hmm, you should really consider switching the palette 21:08:13 <FooBar> changing all pcx files is not fun :( 21:08:26 <andythenorth> nah 21:08:33 <Ammler> that is a bulk job 21:08:44 <andythenorth> however...I'm considering renaming all the filenames beginning 'i_' 21:08:59 <andythenorth> it makes typing to open the file very slow :o 21:09:00 <FooBar> suggestion? 21:09:09 <FooBar> ah... 21:09:11 <andythenorth> just don't prefix them 21:09:32 <FooBar> use a GUI to open the files... 21:09:34 <FooBar> :P 21:09:51 <andythenorth> I do use a GUI :P 21:09:58 <FooBar> that's why I put the i_ there in the first place, so that all industries sit next to each other... 21:10:11 <andythenorth> nice idea, but not necessarily a time saver :) 21:10:35 <FooBar> for me it is if I need to find any of the other files... 21:10:35 <andythenorth> frick 21:10:38 <andythenorth> merge issues 21:10:42 <FooBar> :D 21:10:50 <FooBar> ids.pnfo? 21:10:53 <andythenorth> dunno 21:11:03 <andythenorth> this is a new one on me: abort: branch 'default' has one head - please merge with an explicit rev 21:11:59 <andythenorth> planetmaker: Ammler...advice? ^ 21:12:21 <Ammler> opengfx? 21:12:29 <andythenorth> FIRS 21:12:35 <Ammler> hg heads 21:12:52 <FooBar> if you dump all industries in a subfolder and then get rid of the i_ I'd be happier 21:12:58 <andythenorth> FooBar: that would be fine 21:13:18 <FooBar> ok, then removing the i_ is perfectly fine with me :) 21:13:25 <andythenorth> Ammler: http://pastebin.com/LSiz1pEF 21:14:06 <Ammler> andythenorth: hg pull? 21:14:25 <andythenorth> no changes 21:14:34 <andythenorth> I pulled already, that's what I'm trying to merge 21:14:41 <Ammler> hmm, what are you trying to do, btw.? 21:14:43 <FooBar> anyways, I'm off to bed now 21:14:46 <FooBar> good night! 21:14:49 <andythenorth> bye 21:14:56 <andythenorth> Ammler: commit outstanding changes, then push 21:15:18 <andythenorth> I guess my repo is screwed again? 21:15:19 <Ammler> so you did again not pull before commit? 21:15:29 <andythenorth> n 21:15:31 *** FooBar has quit IRC 21:15:35 <Ammler> how many commits? 21:15:39 <Brot6> FIRS Industry Replacement Set - Feature #1261 (New): Remove i_ prefix from industry templates, mo... (andythenorth) @ http://dev.openttdcoop.org/issues/1261 21:15:40 <andythenorth> but I saw there were changes, so I rolled back the commit 21:15:45 <andythenorth> one commit 21:15:47 <andythenorth> rolled back 21:16:08 <Ammler> then hg pull and hg up? 21:16:16 <Ammler> maybe you forgot the up? 21:16:19 <andythenorth> no changes 21:16:30 <planetmaker> andythenorth, try hg up -rXXX 21:16:37 <planetmaker> where XXX is the rev you want to update to 21:16:52 <planetmaker> maybe hg up -rtip 21:16:53 <Ammler> isn't that tip? 21:17:30 <andythenorth> hg up -r1205 shows 'unkown revision' 21:17:36 <andythenorth> hg up -rtip shows no changes 21:17:57 <andythenorth> hg tip shows 1205 as tip 21:17:59 * andythenorth confused 21:18:10 <planetmaker> hg heads? 21:18:11 <andythenorth> how can 1205 be tip and be an unknown revision 21:18:14 <andythenorth> http://pastebin.com/LSiz1pEF 21:18:47 <planetmaker> hg parent? 21:19:00 <andythenorth> 1204 21:19:26 <planetmaker> and hg ci doesn't work? 21:20:22 <planetmaker> actually... what's what you try to do? 21:20:38 <andythenorth> I have one change I want to commit 21:20:52 <andythenorth> maybe I'll just delete and clone again 21:21:17 <andythenorth> I don't know how I broke it this time, I didn't do anything unusual / risky 21:21:43 <Brot6> OpenGFX - Bug #657: Enable company colours for sweets factory (planetmaker) @ http://dev.openttdcoop.org/issues/657#change-3236 21:23:46 <planetmaker> and you get that message when you want to commit the stuff? 21:24:22 <andythenorth> gah 21:24:26 <Ammler> andythenorth: what hg version you use? 21:24:30 <Ammler> hg --version 21:24:31 <andythenorth> my new clone can't push 21:24:36 <andythenorth> how do I authorise it? 21:25:13 <Ammler> add default-push=https://andy...:pw@push.openttdcoop.org/firs to your .hg/hgrc 21:26:14 <andythenorth> Ammler: authorisation failed 21:26:19 <andythenorth> do I need to clone with ssh not http? 21:26:41 <Ammler> well, ssh is old-style :-) 21:26:51 <planetmaker> bb 15 minutes 21:26:52 <Ammler> you can also add the ssh url to default-push 21:27:08 <Ammler> if you clone with ssh, also push will work 21:27:21 <Ammler> but I use http to pull and https to push 21:27:59 <andythenorth> Ammler: resolved that 21:28:05 <Ammler> http://dev.openttdcoop.org/projects/home/wiki/Mercurial 21:28:19 <Brot6> FIRS Industry Replacement Set - Revision 1205:47c66a002554: Feature: additional layout for Forest (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/47c66a002554 21:28:46 <Ammler> andythenorth: still, which version you use? 21:28:53 <andythenorth> 1.2.1 21:29:01 <Ammler> that is stoneaged 21:29:08 <Ammler> we are at 1.6.x now 21:29:31 <Ammler> macport should have newer version 21:30:08 <andythenorth> running it now 21:39:18 <Brot6> OpenGFX - Revision 486:5ca0eeb034f1: Feature #840: Born Acorns uk signals (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/5ca0eeb034f1 21:41:44 *** frosch123 has quit IRC 21:52:19 *** GT has joined #openttdcoop.devzone 21:54:44 <Brot6> OpenGFX - Revision 487:1a36bea3ed6a: Change: move the toyland signals nfo to a sep. file and incl... (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/1a36bea3ed6a 21:58:57 <Brot6> OpenGFX - Feature #840 (Closed): Improved signal sprites (Ammler) @ http://dev.openttdcoop.org/issues/840#change-3237 22:05:47 <GT> Now NML is progressing nicely, but I did not follow it in great detail, what would it take to convert the 32bpp-extra project to NML? 22:07:10 <Ammler> Hello GT :-) 22:07:22 *** Seberoth has quit IRC 22:07:25 <Brot6> OpenGFX - Revision 488:a2739bb6b899: Cleanup: those specs are outdated, find up2date specs in .de... (Ammler) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/a2739bb6b899 22:07:28 <GT> HI Ammler 22:08:36 <Ammler> you should request 32bpp support from nml :-) 22:08:45 <Ammler> so it does encode the pngs 22:09:21 <GT> True, but currently it uses 8bpp pcxs, first step would be to convert it to nml, or not? 22:10:20 <Ammler> well, that should be possible, but is it worth? 22:10:51 <Ammler> I mean, that grf is quite static, isn't? 22:10:57 <GT> yes 22:12:36 <Ammler> the question is more, is it worth to update the grf with newer graphics and code from opengfx? 22:13:38 <Ammler> and maybe you noticed that we splitted the nfos heavily in the meantime 22:14:15 <Ammler> it might be worth to make the 32bpp extra a branch instead a sep repo? 22:14:15 <GT> not sure, I dont like to provide 8bpp pcx, and coding the offsets etc, just to get them replaced by 32bpp pngs 22:14:41 <GT> splitting up is a good idea I think, anyway 22:14:47 <Ammler> yeah, you shouldn't 22:14:58 <Ammler> or I wouldn't either :-) 22:15:05 <GT> a branch of what? 22:15:11 <Ammler> of opengfx 22:15:29 <Ammler> which would use the needed nfo and pcx from there as #include 22:15:53 * Rubidium wonders whether he proposed an extension to nml that would take the 32bpp sprites and renumber them correctly, get them their correct offsets and then convert the "normal" zoom version (possibly created by scaling) into an 8bpp sprite for the .grf 22:16:28 <Ammler> he, also a good idea :-) 22:17:40 <Ammler> well, the 8bpp images are for those sprites, which miss a 32bpp variant 22:18:48 <Rubidium> Ammler: so it works somewhat transparently; define an 8 bits sprite and it only adds it to the grf, define a 32bpp sprite and it does the renumber/pngcodec magic + downscaling for the grf 22:19:45 <GT> wouldnt the renumbering of the 32bpp sprites need an already renumberd nfo? 22:20:09 <Ammler> Rubidium: or give the possiblity to define 8bpp and 32bpp sprites 22:20:20 <GT> Though the idea sounds great 22:20:42 <Ammler> GT, now you use some unportable .bat files 22:20:53 <Ammler> wouldn't nml or nfo be better 22:20:58 <GT> what is .bat? 22:21:16 <Ammler> those batch scripts Ben uses for his sprites 22:21:22 <Ammler> to encode the pngs 22:21:46 <Ammler> that is imo like a nfo 22:22:21 <GT> I know, Im more used to shell scripts, and yeah nml would be much better, esp when I dont have to determine offsets or size of 8bpp pcxs 22:22:24 <Ammler> just not portable and specified 22:22:49 *** Seberoth has joined #openttdcoop.devzone 22:23:16 <GT> just wondered the work flow, if specing pngs in nml/nfo would work, that would be best 22:23:19 <planetmaker> [00:15] * Rubidium wonders whether he proposed an extension to nml that would take the 32bpp sprites and renumber them correctly, get them their correct offsets and then convert the "normal" zoom version (possibly created by scaling) into an 8bpp sprite for the .grf <-- it sounds familiar. But it's probably not in the bug tracker ;-) 22:23:33 <Ammler> also a nfo real sprite could be extended for example add the png at end after the offsets 22:23:41 <Rubidium> planetmaker: ofcourse not, it's on the forum 22:23:48 <planetmaker> :-) 22:24:32 <planetmaker> just wondered the work flow, if specing pngs in nml/nfo would work, that would be best <-- NML reads pngs 22:24:51 <Ammler> :-) 22:25:03 <Ammler> but opengfx devs aren't allowed to use it :-P 22:25:07 <planetmaker> it has yet no conversion. But it doesn't need that really 22:25:22 <planetmaker> Ammler: you are. But _source_ of opengfx is still nfo and pcx 22:25:28 <Ammler> :-) 22:25:53 <planetmaker> when there's a first release of NML, I'll happily add NML support 22:26:01 <Ammler> anyway, did you review the signals? 22:26:09 <planetmaker> It's already 80% done anyway 22:26:12 <Ammler> is that ok that way? 22:26:18 <planetmaker> I didn't yet look 22:27:52 <Ammler> I wonder, if 2006TTD will make the templated files 22:28:07 <Ammler> else I will do that too, it isn't that much 22:30:14 <GT> I wondering if it is possible to start with an nml file referring to png, pngcodec the pngs, and then convert to 8bpp and create the nfo. Probable the biggest hurdle is the determination of the offsets, since they are different for ground tiles and vehicles 22:30:30 <planetmaker> well, yes, Ammler :-) 22:30:35 <GT> s/I wondering/ I was wandering/ 22:30:38 <planetmaker> looks fine to me 22:30:53 <GT> s/wandering/wondering 22:31:00 <planetmaker> :-D 22:31:33 <Ammler> GT: finding the right colors isn't that easy 22:31:37 <planetmaker> GT: it certainly is possible. But offsets will need adjustment in any case, I guess 22:31:52 <planetmaker> and colours will be interesting to get right. But not impossible, I say 22:32:00 <Ammler> gimp does that quite good, I am not sure, how well python-imging would do that 22:32:15 <GT> yes, vehicles using some kind of centre of gravity and ground tiles the top centre as reference point 22:32:47 <GT> which makes it difficult to automate, though nml may have knowledge about the method to use 22:33:17 <planetmaker> nml is not more intelligent with sprite alignment than NFO. 22:33:23 <planetmaker> it's all manual work 22:33:23 <Ammler> planetmaker: if you have the same sprite in 32bpp and 8bpp, the offsets are the same 22:33:34 <Ammler> or am I wrong? 22:33:36 <planetmaker> you just may use mathematical formula for the positions 22:33:42 <GT> colors are probably difficult, 32bpp->palette isnt straightforward, the other way is easier 22:33:52 <planetmaker> but if the size is the same. Then the same alignment should be good 22:34:05 <planetmaker> I thought about re-scaling 22:34:08 <Ammler> GT: we used some 32bpp sprites in opengfx 22:34:14 <Ammler> you find those quite well :-) 22:34:16 <planetmaker> If no re-scaling, then no offset change. I recon 22:34:19 <Ammler> easy* 22:34:56 <Ammler> like the artic hotel or the tropic church 22:35:00 <GT> correct, but when I start with 32bpp pngs, the offset would be different for vehicles or ground, when the sprite has the same dimension 22:35:12 <planetmaker> hu? 22:35:28 <planetmaker> Well. Something you cannot do, is automatic alignment 22:35:36 <planetmaker> You have to align each sprite separately 22:35:43 <planetmaker> The only exception is really ground tiles 22:35:57 <Ammler> GT: the offset is different because your sprite has other sizes? 22:36:02 <planetmaker> One can come up with formula for house sprites and one-tile width 22:36:17 <planetmaker> But other than that: manual work until it looks right 22:36:30 <Ammler> nah, everything is somehow logical 22:36:37 <planetmaker> though there are ways to put that into formula, it's tedious 22:36:42 <Ammler> e.g. I have same offset for every signal 22:36:49 <planetmaker> yes, of course 22:37:06 <planetmaker> But only if all sprites are the same size. 22:37:17 <planetmaker> If different signals have different widths, the offsets are not the same 22:37:22 <GT> Ammler, no, because ground tiles and vehicle sprites are handled differently, so I guess we would have to specify the offset manually in any case, the size of the sprite can be determined automagically for png 22:37:23 <Ammler> yep 22:37:48 <Ammler> GT but the sizes/offsets are the same in 32bpp and 8bpp 22:37:54 <Ammler> you need to adjust only one 22:37:58 <Ammler> would* 22:38:33 <GT> that would be the offset, like I said the size can be determined from the png 22:39:08 <Ammler> how do you "code" the png now? 22:39:11 <GT> so nml input would have to be the png file name, and the offset 22:39:17 <Ammler> be looking ingmae? 22:39:46 <Ammler> and the pcx 22:40:02 <Ammler> and possibly the additional zoom level pngs 22:40:17 <Ammler> s/pcx/8bpp-png/ 22:40:24 <GT> with png_codec, for ground tiles you can do a best first guess, depending on the height and width of the sprite and refine that in game, for vehicles too, but then the formula is different 22:42:44 <Ammler> 1238 sprites/pcx/house.png 146 6584 01 21 4 -1 -19 sprites/32bpp/house.png [sprites/32bpp/house_z1.png...] 22:43:03 <Ammler> how a nfo line could look? 22:44:34 <GT> so start with nml, offset and (pngcodeced)symbolic png file name -> create nfo for pcx ->renumber pngs + create 8bpp pcx 22:44:56 <Ammler> no, no need for pngcodec 22:45:14 <Ammler> that would be done by nfml 22:45:15 <Ammler> nml 22:46:08 <Ammler> there is no pcx in nml 22:46:13 <GT> no, I mean the grf creator would have to provide pngcodeced pngs, he would have to test it ingame anyway and nml could use the offset 22:46:14 <Ammler> already 22:46:31 <GT> There is no pcx? 22:46:39 <planetmaker> nml can read png natively 22:46:44 <planetmaker> swedish rails has no pcx 22:46:45 <Ammler> nml creates grf from png 22:47:13 <planetmaker> (or any other paletted image format readable by the python image library) 22:47:23 <GT> really? didnt know that, and liking it better by the minute 22:47:54 <planetmaker> but it needs the correct palette. 22:48:01 <Ammler> GT, why using pngencoded pngs? 22:48:13 <Ammler> why not let nml encode it 22:48:20 <GT> you cant test pngs without pngcodecing it 22:48:30 <Ammler> test? 22:48:51 <GT> when creating the png 22:48:59 <GT> and want to see it ingame 22:49:01 <Ammler> yes, that guy should use nml 22:49:26 <Ammler> to make a tar which he can load 22:49:37 <Ammler> easier as making a batch file or whatever 22:50:03 <GT> that would be really nice, but how would nml (interpreter) determine the correct offset? 22:50:17 <Ammler> you need to define that in the nml 22:50:25 <Ammler> like you do that in the .bat now 22:50:33 <Ammler> or in your .sh 22:50:44 <Ammler> or whatevery ou use to encode it now 22:50:48 <GT> right, and how would you do that? by testing it ingame, which would require pngcodecing 22:51:34 <GT> that's how it is done now, pngcodec the png, test ingame, adapt the bat/sh and try again 22:51:35 <Ammler> well, you would need to talk with the nml devs 22:51:46 <Yexo> GT: I think what Ammler means is that instead of just providing a 8bit pcx/png file in the nml source you also specify a 32bpp png file, nml then remanes the file to the correct number and pngcodecs it 22:51:55 <Yexo> that's not possible currently, but that could be implemented 22:52:12 <Ammler> ah, yes, of course 22:52:22 <Ammler> I meant that as a feature request to nml :-) 22:52:49 <Yexo> and imo if we go that way we should leave the "1 sprite per 32bpp png file" approach 22:53:09 <Yexo> of course it's still needed for the output, but there is no reason nml can't use one big png file as input and make the smaller files itself 22:53:10 <Ammler> Yexo: does that matter? 22:53:24 <Yexo> no, it probably makes it easier for the artists 22:53:28 <GT> Yexo, I understood, but I wondered how the png creator would specify the offset in nml without pngcodecing it himself when creating 22:53:31 <Ammler> I mean, I would already do that with 8bpp 22:53:52 <Yexo> GT: exactly the same as for 8bpp sprites 22:54:18 <Ammler> and exactly like he does that with his .batch or shell skript or whatever he uses 22:55:19 *** Seberoth has quit IRC 22:56:11 <Yexo> http://pastebin.ca/1919061 it could for example work like this 22:56:47 <Yexo> here I'm assuming that the 32bpp file has exactly the same layout/sprite sizes as the default 8bpp sprites 22:57:05 <Yexo> if they do a template would make things even easier 22:57:18 *** ODM has quit IRC 22:57:56 <Ammler> is it a requirement to have all sprites in one file in nml? 22:58:09 <Yexo> no, you can use as many differnt files as you want 22:58:12 <GT> ok, so the workflow would be: create an nml with a best guess offset, and provide an uncoded png, then start the nml interpreter that creates a renumbered pngcodeced png and a grf file test that ingame 22:58:39 <Ammler> or just a tar 22:58:52 <GT> and adapt the offsets when necessary, while nml creates the 8bpp pcxs during the process 22:59:27 <Yexo> nml never creates 8bpp pcx files, it just writes the grf with the 8bpp sprites in it and some png files 22:59:27 <Ammler> nml does write the grf directly, no need for pcx :-) 22:59:31 <GT> taring is only needed when the set is complete imo, no need to do that during testing 22:59:46 <Yexo> nml should never create the tar, just a proper directory structure 22:59:52 <Yexo> the makefile can then tar it if you want that 22:59:57 <Yexo> or whatever else you use 23:00:03 <GT> but can openttd handle grfs with pngs? 23:00:26 <Yexo> GT: in a grf each sprite is just an array of bytes 23:00:33 <Yexo> it doesn't matter what the original source was 23:01:09 <Ammler> that is what grfcodec makes it to, today it would make a png 23:01:13 <Yexo> in theory I could code nml to read a 32bpp png, convert each pixel to the closest color that is in the palette and write that to the grf file 23:01:16 <GT> ok, but that would need changes to the openttd code, i think it assumes pcx now? 23:01:38 <planetmaker> GT: no ;-) 23:01:40 <Ammler> NO 23:01:43 <planetmaker> it assumes grf format 23:01:46 <planetmaker> which is neither 23:01:52 <Yexo> openttd assumes grf format, which is neither pcx nor png 23:01:59 <planetmaker> :-) 23:02:02 <Ammler> pcx is made with grfcodec from grf 23:02:42 <Yexo> the image format of sprites in the grf is just size and then for each pixel an offset in the color palette 23:03:03 <Yexo> the palette itself is not stored in the grf file (unlike in pcx/png files) 23:05:24 <GT> Ok, I'll rephrase, palette is an 8bpp concept, openttd does not handle 32bpp graphics by default, it assumes 8bpp graphics in the grf? 23:05:36 <Yexo> yes 23:05:43 <Yexo> and I never proposed to change that 23:06:24 <GT> so if i provide a 32bpp png to nml, it would have to be converted to an 8bpp format 23:06:33 <Ammler> why? 23:06:47 <Yexo> if you only provide a 32bpp png and no 8bpp default then yes, it'd have to be converted 23:07:16 <Ammler> it would renumber to the sprite defined in the nml and then saved in the "32bppfolder" like now 23:07:20 <Yexo> I think it's better if you would always have to provide both an 8bpp png and a 32bpp replacement, so nml can use the 8bpp for writing the grf 23:07:29 <Ammler> and pngencoded 23:07:46 <Yexo> Ammler: because nml has to write the grf, if you only have a 32bpp file as input you have to convert it :) 23:08:23 <Ammler> Yexo: or you could use a dummy transparent sprite 23:08:29 <Ammler> or whatever 23:08:52 <Yexo> of course there are multiple options in that case :) 23:09:01 <GT> So were back at what I said before, providing a 32bpp pngcodeced png and an nml file would be enough to create the rest 23:09:25 <Ammler> _not_ encoded 23:09:28 <Ammler> that is part of nml 23:09:37 <Yexo> the 32bpp input file doesn't have to be pngcodeced yet 23:09:41 <Yexo> that part can easily done by nml 23:09:48 <Ammler> it should, (imo) 23:10:03 <GT> only if i provide an 8bpp graphic too 23:10:23 <Yexo> that has nothing to do with it 23:11:18 <GT> maybe im wrong, but if i provide an uncoded png and an nml file, how would the nml interpreter generate the offsets? 23:11:30 <Ammler> you have those in the nml 23:11:41 <Ammler> check the example paste 23:12:00 <Ammler> xpos, ypos, compress, XOFF, YOFF 23:12:02 <GT> and how would i know what to put in the nml file, when I cant test 23:12:09 <Ammler> might be other order... 23:12:23 <Ammler> how do you do it now? 23:12:33 <Ammler> how you know, what to give the pngcodec? 23:12:34 <Yexo> GT: how do you know how to pngencode a sprite when you can't test it before you have pngcodec it? (situation currently) 23:12:35 <GT> pngcodec and test 23:12:42 <Yexo> answer: you make an educated guess and test the result 23:12:59 <Ammler> pngcodec doesn't need offsets? 23:13:03 <Yexo> of course it does 23:13:13 <GT> it only needs offsets, no sizes 23:13:17 <Ammler> well, you can always start with 0 :-) 23:13:40 <Yexo> that is because pngcodec assumes the complete png file is 1 single sprite 23:13:46 <Yexo> so the size is the size of the png file 23:14:00 <Ammler> python-imaging not able to? 23:14:23 <Ammler> well, not sure, what is easier 23:14:41 <Ammler> crop pngs or define sprite sizes 23:14:42 <Yexo> there is no technical reason every sprite as input for nml should be in a differnt file, you can have multiple sprites in one 32bpp png and nml can split them to multiple output files for you 23:14:50 <GT> ok, summarize, provide an uncoded png, and do the educated guess for offset in nml, and nml generates the grf and pngcodeced renumbered pngs 23:14:58 <Yexo> yes 23:15:45 <Yexo> the advantage of having one file with multiple sprites is that you can take the 8bpp graphic file as example and just replace all sprites, taking care to keep the exact same sizes for all sprites, if you do that the same offsets should work 23:15:49 <GT> and the grf contains the 8bpp data as well for those blitters? Im starting to drewl 23:16:00 <Ammler> Yexo: but nml would need to crop the input png to single pngs for openttd 23:16:11 <Ammler> (I assume) 23:16:21 <Yexo> Ammler: yes, but it already needs to do that for the 8bpp input 23:16:48 <planetmaker> hm... ugly commit to fix the maglev track sprites? 23:16:58 <Ammler> why? 23:17:32 <Yexo> GT: I'm not completely up to date on the differences between trunk and EZ in the 32bpp png input 23:18:13 <planetmaker> Ammler: ugly as in just replace the wrong sprites in the HUGE pcx files 23:18:21 <planetmaker> which is actually TWO huge pcx files 23:18:27 <planetmaker> for no good reason I see 23:18:28 <Ammler> no pcx editing 23:18:40 <Ammler> add a new file with those sprites 23:18:43 <planetmaker> :-) 23:19:15 <planetmaker> that doesn't make sense in this case either as it's only single track sprites out of context 23:19:18 <Ammler> I also have added a 1sprite pcx 23:20:12 <planetmaker> having one set of tracks in one file makes sense 23:20:36 <Ammler> e.g. http://dev.openttdcoop.org/projects/opengfx/repository/changes/sprites/pcx/gui/graphs.pcx 23:20:37 <planetmaker> but that means... heavy cutting, editing, re-alignment :-( 23:20:47 <planetmaker> yes 23:20:57 <Ammler> or 2 sprites: http://dev.openttdcoop.org/projects/opengfx/repository/changes/sprites/pcx/gui/savemenu.pcx 23:21:00 <planetmaker> But the GUI sprites are independent of eachother somewhat 23:21:10 <planetmaker> the track sprites not really 23:21:30 <Ammler> then copy the whole track sprites out there 23:21:50 <planetmaker> that's the clean solution, yes 23:22:04 <planetmaker> But then not before sleeping anymore 23:22:08 <Ammler> you can keep the size of the pcx 23:22:25 <Ammler> just replace the whole rest with pure white 23:22:33 <planetmaker> No... it's the infra0X pcx 23:22:35 <Ammler> so you don't need to edit the offsets 23:22:51 <Ammler> I meant the positions 23:22:54 <planetmaker> they're thousands of pixels 23:23:03 <planetmaker> in the y-dimension 23:23:19 <Ammler> well, you can simply calculate that 23:23:24 <Ammler> and keep xpos 23:23:35 <planetmaker> yeah, I guess 23:23:38 <planetmaker> later :-) 23:23:55 <Ammler> anyway better make a copy as replace the exisiting 23:23:58 <planetmaker> it's quite a bit work for all sprites and climates 23:24:06 <planetmaker> hu? 23:24:15 <planetmaker> why? 23:24:19 <Ammler> a copy of infra.pcx 23:25:21 <planetmaker> why is it better to add another big file? 23:25:32 <Ammler> to keep history at least 23:25:44 <GT> Yexo: 32bpp EZ sprite format is exactly the same, only difference is the naming convention: a postfix _z0 or _z1 is used for the filenames, and there could be a off by 1 or 2 pixels when the png creator does not create a png size that is divisible by 4 (or pngcodec it with an offset that is not divisibable by 4) 23:25:49 <planetmaker> history of pcx is kept... 23:25:51 <Ammler> not everyone is able to make a proper diff of a binary 23:26:01 <planetmaker> the repo has it 23:26:20 <Ammler> so I change something in the pcx and you are able to tell me what I have changed? 23:26:48 <Ammler> hmm, I know it is possible 23:26:56 <Ammler> but I wouldn't know how :-) 23:28:03 <planetmaker> it's a hassle, yes 23:28:22 <Ammler> IMO, it is worse to edit a pcx then using nml :-P 23:28:45 <planetmaker> nice. My git diff for that patch is 1.6M ;-) 23:29:13 <planetmaker> and redmine refused to attach it to the issue 23:29:23 <Ammler> he? 23:29:26 <planetmaker> 'request too large' 23:29:30 <Ammler> 5MB is limit, afgaik 23:29:51 <planetmaker> 413 Request Entity Too Large 23:29:53 <planetmaker> nginx/0.7.65 23:29:59 <Ammler> oh 23:30:08 <Ammler> a nginx limit? 23:30:13 <planetmaker> seems like 23:33:42 <planetmaker> but don't worry about that 23:34:51 <planetmaker> bed time now. 23:36:15 <planetmaker> so have also a good night :-) 23:36:34 <Ammler> fixed 23:37:57 <SmatZ> good night, planetmaker :) 23:42:37 <Ammler> good night pm and SmatZ 23:42:41 <Ammler> and rest 23:42:46 <SmatZ> good night, Ammler :) sleep well 23:43:01 <Ammler> thanks, same to you :-) 23:44:54 *** KenjiE20 has quit IRC 23:49:13 *** GT has left #openttdcoop.devzone